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I.  INTRODUCTION 


A,  BACKGROUND 

The  United  States  Coast  Guard  (USCG)  faces  a  challenge  getting  the  right  people, 
in  the  right  places,  at  the  right  times.  According  to  the  Government  Accountability 
Office,  this  challenge  was  compounded  when  the  USCG  transitioned  from  the 
Department  of  Transportation  to  the  Department  of  Homeland  Security  (DHS)  in  2003, 
and  subsequently  as  its  role  in  homeland  security  expanded  (United  States  General 
Accounting  Office,  2003).  Currently,  the  USCG  is  charged  with  the  execution  of  11 
missions  including  ports,  waterways,  and  coastal  security;  drug  interdiction,  aids  to 
navigation,  search  and  rescue,  living  marine  resources,  marine  safety,  defense  readiness, 
migrant  interdiction,  marine  environmental  protection,  ice  operations,  and  other  law 
enforcement.  As  such,  the  USCG  is  required  to  be  agile  and  responsive  to  changing  threat 
conditions  in  many  different  operating  environments. 

Determining  manpower  requirements  and  getting  the  right  people,  in  the  right 
place,  at  the  right  time,  is  an  ongoing  and  complex  process.  The  focal  point  is  to  identify 
the  optimal  number  of  people  with  the  right  knowledge,  skills,  and  abilities.  Too  few  or 
underqualified  people  may  adversely  impact  safety,  readiness,  and  mission  execution. 
Too  many  or  overqualified  people  may  siphon  funding  from  other  priorities.  Currently, 

the  USCG  lacks  a  system-wide  methodology,  an  integrated  set  of 
applications,  and  common  data  warehouses  needed  to  fully  develop  an 
effective  and  efficient  manpower  requirements  engineering  and 
management  program.  The  lack  of  an  objective  control  mechanism  for 
determining  the  right  number  and  skill  mix  of  manpower  creates 
inefficiencies  in  the  ability  to  provide  the  right  manpower  to  effectively 
meet  the  workload  demands  of  our  organization.  (Papp,  2006,  p.  1). 

In  May  2006,  Admiral  Thad  W.  Allen  became  the  23rd  Commandant  of  the  Coast 
Guard.  The  Admiral’s  goal  for  his  tenure  was  to  improve  mission  execution.  He 
communicated  his  vision  to  the  organization  via  Commandant  Intent  Action  Orders 
(CIAO).  Order  number  8,  “Human  Resource  Strategies  to  Support  USCG  Maritime 
Strategy,”  was  published  in  August  2006.  This  order  called  for  a  process  to  ensure  “the 
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right  mix  of  human  capital  to  support  mission  execution”  (Allen,  2006,  p.  1).  Two 
speeific  initiatives  outlined  in  the  CIAO  were  “to  establish  methods  to  use  measured 
workload  data  to  define  human  eapital  requirements,”  and  to  “design  and  begin 
implementation  of  an  automated  information  system  that  will  allow  individuals,  unit 
eommanders,  and  program  managers  to  eompare  eompeteneies  held  with  eompeteneies 
required  by  speeifie  jobs  or  types  of  jobs  for  the  purpose  of  defining  the  gaps”  (Allen, 

2006,  p.  2). 

CIAO  8  was  direeted  to  Human  Resourees,  CG-1.  In  Oetober  2006,  the  Human 
Resouree  Strategy  and  Capability  Development  Offiee,  CG-IB,  responded  by 
establishing  the  Manpower  Requirements  Determination  (MRD)  Enterprise  Development 
Team.  “The  prineipal  goal  of  ereating  an  MRD  enterprise  is  to  inerease  our  ability  to 
aceount  for  resourees  within  the  Coast  Guard...”  (Papp,  2006,  p.  1).  One  of  the  MRD 
Enterprise  Development  Team’s  tasks  was  to  “develop  [a]  centralized,  web-enabled 
MRD  data  repository  to  eapture  work  measurement  data”  (Papp,  2006,  p.  6).  In  Oetober 
2008,  the  expeetations  of  the  MRD  Enterprise  Development  Team  were  updated  to 
inelude  more  speeifically  the  development  of  a  Manpower  Requirements  Determination 
Automated  Information  System  (MRD  AIS)  and  the  ereation  of  a  temporary  MRD 
database  to  house  extant  and  future  data  (Breekenridge,  2008,  p.  4). 

The  construetion  of  a  MRD  AIS  exceeded  the  capabilities  of  USCG  employees  so 
the  serviee  eontraeted  an  information  teehnology  company  to  build  the  system.  “The 
primary  goal  of  the  MRD  AIS  projeet  is  to  ereate  a  verifiable,  repeatable,  and  defendable 
program  that  eolleets,  measures,  and  analyzes  the  human  eapital  needed  to  perform  Coast 
Guard  missions”  (Commandant  (CG-lBl),  2008a,  p.  8).  More  speeifieally,  the  projeef  s 
business  objeetives  (BO)  called  for  the  system  to: 

•  Reduee  the  proeess  eyele  time  assoeiated  with  workload  demand 
evaluation,  manpower  requirements  determination,  and  labor 
eonsumption  measurement; 

•  Develop  a  standard  proeess  for  determining  the  manpower 
requirements  neeessary  to  meet  mission  objectives; 
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•  Increase  the  quality  of  work  produets  assoeiated  with  human 
eapital  deeision  support;  and, 

•  Improve  visibility  of  the  USCG  workforee,  human  resouree 
demand,  demand  eonsumption,  and  demand  eost  information 
(Commandant  (CG-lBl),  2008b,  p.  14). 

Also,  the  MRD  AIS  was  to  have  three  primary  eomponents: 

•  A  eentral  repository  to  house  workload  data; 

•  An  optimization  meehanism  to  determine  the  right  amount  and  mix 
of  manpower  within  an  organization  strueture;  and, 

•  A  modeling  and  simulation  proeess  to  generate  alternatives  to 
support  the  best  business  ease  for  eaeh  alternative  (Commandant 
(CG-lBl),  2008b,  p.  17). 

To  date,  the  eontraetor-built  MRD  AIS  nor  any  other  MRD  AIS  has  been 
integrated  into  USCG  Manpower  Requirements  Analysis.  No  formal  doeumentation 
exists  as  to  why  the  MRD  AIS  was  never  adopted.  Informal  eommunieation  with  the 
USCG  Manpower  Requirements  Determination  Division  suggest  that  diffieult  interfaee, 
ineomplete  identifieation  of  faetors  that  determine  manpower  requirements,  and  non¬ 
standard  terminology  have  prevented  the  system  from  being  integrated  into  Division 
operations. 

Sinee  the  delivered  MRD  AIS  is  not  being  used,  the  USCG  is  eontinuing  to  use  an 
antiquated  and  laborious  proeess  to  determine  manpower  requirements.  The  proeess 
involves  spreadsheets  and  manual  ealeulations.  These  tasks  ean  be  easily  eompleted  and 
synthesized  by  a  database  whieh  would  translate  to  substantial  time-savings  and 
effieieney.  Therefore,  developing  a  robust  MRD  AIS  remains  a  priority. 

The  development  of  a  MRD  AIS  also  has  benefits  beyond  time-savings.  For 
example,  it  would  improve  the  standardization  of  manpower  requirements  aeross  the 
serviee.  It  would  alleviate  resouree  managers  from  being  influeneed  by  loeal  or 
programmatie  needs,  and  eliminate  similar  unit  types  and  requirements  from  being 
manned  differently.  Next,  a  MRD  AIS  would  inerease  the  transpareney  of  manpower 
requirements  at  all  levels  and  positively  eontribute  to  deeision  making.  Speoifieally 
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increased  visibility  would  not  only  inform  staffing  standards  but  recruiting,  training,  and 
advancement  initiatives  as  well. 

B,  PURPOSE 

The  purpose  of  this  study  is  to  demonstrate  the  potential  value  in  implementing  a 
MRD  AIS  in  the  USCG.  More  specifieally,  the  objective  is  to  model  the  factors  that 
contribute  to  determining  manpower  requirements  in  an  entity-relationship  diagram 
(ERD),  and  subsequently  test  the  model  using  a  relational  database.  The  intent  of  a  MRD 
AIS  is  to  improve  the  accuracy  of  determining  manpower  requirements,  alleviate  time 
intensive  manual  processes,  standardize  manpower  analysis  across  the  USCG,  increase 
transparency,  bolster  the  service’s  ability  to  adapt  to  changing  conditions,  optimize 
manpower  allocation,  and  identify  alternative  staffing  solutions.  Ultimately,  the  purpose 
of  the  study  is  to  contribute  to  improved  efficiency  within  CG-IB. 

C.  SCOPE  AND  METHODOLOGY 

This  project  includes  a  literature  review,  an  ERD,  and  a  relational  database  for 
test  and  evaluation.  The  literature  review  is  limited  to  a  presentation  and  comparison  of 
USCG  and  Navy  processes  for  determining  Eleet  and  shore  manpower  requirements.  The 
comparison  is  made  between  the  USCG  and  the  Navy  due  to  the  similar  nature  of  their 
mission  requirements  and  aggregate  resources  for  which  requirements  are  determined. 
Industry,  Air  Eorce,  Army,  and  Marine  Corp  processes  are  not  reviewed.  An  ERD  will  be 
constructed;  it  will  model  USCG  entities  and  attributes  that  contribute  to  determining 
manpower  requirements.  The  model  is  original  and  not  an  extension  of  any  contractor’s 
work.  A  relational  database  will  be  built,  and  tested  with  simulated  data.  The  primary 
method  of  testing  the  model  and  relational  database  will  be  via  queries.  The  testing  will 
be  considered  successful  when  a  query  produces  a  spreadsheet  or  table  similar  to 
produets  found  in  MRA  Reports.  No  code  was  executed  to  perform  mathematical 
computations  or  to  yield  summary  information. 
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D,  ORGANIZATION  OF  STUDY 

This  study  is  comprised  of  four  chapters  that  include:  Introduction,  Overview  of 
MRD,  Description  of  Method  and  Analysis;  and  Summary,  Conclusions,  and 
Recommendations.  Chapter  II  is  the  Overview  of  MRD;  it  is  the  literature  review. 
Chapter  III  is  the  Description  of  Method  and  Analysis.  It  presents  and  explains  the  ERD 
and  relational  database.  Simulated  data  is  used  to  test  the  relational  database,  and  the 
results  are  described.  Chapter  IV  is  the  Summary,  Conclusions,  and  Recommendations. 
This  chapter  is  a  compellation  of  the  study’s  findings,  and  prescribes  what  may  also  be 
done  to  advance  the  implementation  of  an  MRD  AIS  in  the  USCG. 
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II.  MRD  OVERVIEW 


This  chapter  summarizes  the  United  States  Coast  Guard  (USCG)  and  Navy 
proeesses  for  determining  fleet  and  shore  manpower  requirements,  and  identities 
similarities  and  differenees  between  the  proeesses.  The  literature  reviewed  is 
predominantly  USCG  and  Navy  publications.  Note:  the  USCG  Staffing  Logic  and 
Manpower  Requirements  Manuals,  Volumes  II  through  IV,  whieh  are  reviewed  as  part  of 
this  project,  are  in  draft  form  at  this  writing  and  may  be  subject  to  change  prior  to 
publication. 

Proximity  to  Navy  manpower  subjeet  matter  experts,  the  similarity  between  the 
USCG  and  the  Navy,  and  the  presenee  of  USCG  members  at  the  Navy  Manpower 
Analysis  Center  (NAVMAC)  motivated  me  to  compare  the  USCG  Manpower 
Requirements  Determination  (MRD)  proeess  with  the  Navy  MRD  proeess,  as  oppose  to 
the  proeess  of  another  serviee.  Further,  the  Navy  proeess  influenced  the  USCG  proeess, 
so  there  is  benefit  to  understanding  the  similarities  and  differences. 

Regardless  of  the  service,  the  focal  point  of  manpower  requirements 
determination  is  to  get  the  right  people,  to  the  right  places,  at  the  right  times,  with  the 
right  skills.  Accurate  manpower  requirements  determination  ensures  a  ready  foree,  and 
safe  and  effective  mission  execution.  Shortage  or  excess  of  manpower  is  the  catalyst  to 
compromised  mission  execution  or  waste,  respectively. 

A,  USCG  MRD 

The  name  of  the  Coast  Guard’s  proeess  for  determining  manpower  is  the 
“Manpower  Requirements  Process”;  it  has  three  eomponents.  They  are  the  Manpower 
Requirements  Analysis  (MRA)  Proeess,  the  MRD,  and  the  Capabilities  Reeoneiliation 
Process  (CRP).  The  MRA  Process  has  three  phases.  Phase  I,  II,  and  III:  Requestor 
Alignment,  Mission  Alignment,  and  HR  System  Alignment,  respectively.  The  MRD  is  a 
product  of  the  MRA  Proeess.  The  CRP  also  has  three  phases.  Phase  IV,  V,  and  VI: 
Program  Alignment,  Resource  Alignment,  and  Establishment  of  Manpower  Standards 
respectively.  The  Manpower  Requirements  Proeess,  its  components  and  phases  are 
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shown  in  Figure  1.  The  foeal  point  of  this  project,  however,  is  the  MRA  process,  which  is 
described  at  length  in  the  following  paragraphs. 


Manpower 
Requirements 
Process 


MRA  Process 


Phase  1  ^ 

Phase  2  ^ 

Phase  3  ^ 


Phase  4  ^ 
Phase  5  ^ 


Phase  6  ^ 


Figure  1.  USCG  Manpower  Requirements  Process. 


1,  MRA  Levels 

There  are  four  levels  of  MRAs;  listed  in  order  of  increasing  analytical  rigor,  they 
are: 

•  MRA  Level  1 -Manpower  Estimate  Report  (MER) 

•  MRA  Eevel  2-Workload  Consolidation 

•  MRA  Eevel  3-Workload  Validation 

•  MRA  Eevel  4-Workload  Observation. 

The  MRA  Level  is  determined  before  the  MRA  begins.  The  MRA  level  is  determined  by 
a  number  of  things  including  but  not  limited  to  the  purpose  of  completing  the  MRA,  the 
time  available,  the  program  requirement,  and  the  OE’s  complexity.  Regardless  of  the 
MRA  Level,  Phases  1-3  are  completed  for  each  MRA. 

Although  included  as  part  of  the  hierarchy  of  MRAs  completed  in  the  USCG,  a 
MRA  Level  1-MER  does  not  meet  the  analytical  rigor  of  a  true  MRA.  An  MRA  Level  1 
is  conducted  when  undefined  mission  requirements  exist,  for  example,  as  a  result  of  a 
system  acquisition.  An  MRA  Level  1,  however,  is  key  documentation  for  a  subsequent 
MRA  Level  2,  3,  or  4  after  mission  requirements  are  determined  and  there  exists  baseline 
workload  data. 
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As  the  degree  of  analytical  rigor  increases  so  does  the  level  of  intrusiveness  into 
the  organizational  element  (OE),  a  unit  or  a  portion  of  a  unit.  MRA  Level  2  is  almost 
exclusively,  and  MRA  Levels  3  and  4  begin  with,  a  thorough  review  of  policy  documents 
and  related  resources.  MRA  Levels  3  and  4  use  surveys  and  interviews  of  subject  matter 
experts  to  validate  work  and  collect  workload  data.  In  MRA  Level  4,  the  MRA  analyst 
visits  the  OE  to  observe  directly  the  work  and  to  collect  workload  data. 

2,  Before  the  MRA  Process  Can  Begin 

An  MRA  for  fleet  or  shore  OEs  is  initiated  via  an  MRA  request  to  the  Manpower 
Requirements  Determination  Division,  CG-1B4.  The  person,  office,  or  command  that 
files  the  MRA  request  is  the  “requestor.”  The  MRA  request  is  evaluated  to  determine 
what  type  of  analysis  will  meet  the  needs  of  the  OE  for  whom  the  MRA  request  was 
submitted.  Once  a  mutual  decision  is  made  in  regard  to  the  best  analysis  method,  the 
MRA  request  is  added  to  the  MRA  Prioritization  List  managed  by  CG-1B4. 

CG-1B4  does  not  have  enough  resources  to  complete  every  MRA  request,  nor  the 
resources  to  complete  the  MRAs  they  commit  to  without  contractor  support.  Whether  an 
MRA  is  completed  by  organic  or  contracted  resources  depends  on  available  funding, 
MRA  priority,  OE  size  and  type,  timeline,  etc. 

The  final  actions  before  Phase  1  begins  are  assignments  of  MRA  personnel,  and 
the  completion  of  the  Performance  Work  Statement  (PWS).  Once  it  is  decided  that  a 
particular  MRA  will  be  completed,  a  team  will  be  assigned  if  the  MRA  is  to  be 
completed  with  organic  resources,  or  a  team  leader  will  be  assigned  to  act  as  a  project 
manager  if  the  MRA  is  to  be  completed  with  contracted  resources.  Regardless,  if  organic 
or  contracted  resources  are  completing  the  MRA,  a  PWS  is  completed.  A  PWS  is 
essentially  a  contract,  describing  what  products  and  services  will  be  delivered.  When  a 
contractor  is  completing  the  MRA,  the  PWS  is  fiscally  binding  and  guides  the  MRA 
throughout  the  entire  process. 
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3,  Phase  I-Requestor  Alignment 

Phase  I,  Requestor  Alignment,  is  simple.  It  begins  with  the  Alignment  Meeting 
and  eoneludes  upon  the  submission  of  the  Alignment  Report.  The  Alignment  Meeting  is 
the  forum  where  OE  representatives  meet  with  the  respeetive  CG-1B4  Analysis  Team 
and  exehange  expeetations.  At  a  minimum,  goals,  objeetives,  and  timeline  are  discussed. 
The  required  Alignment  Report  captures  relevant  project  information  and  concludes 
Phase  I. 

4.  Phase  II-Mission  Alignment 

Phase  II,  Mission  Alignment,  is  much  more  involved  than  Phase  I.  Phase  II 
includes  the  identification  and  measurement  of  work,  the  recognition  of  assumptions  and 
constraints,  and  the  application  of  allowances.  To  help  clarify  the  process.  Phase  II  has 
guiding  principles  and  core  assumptions  that  direct  the  Phase. 

Three  of  the  four  guiding  principles  are  particularly  notable  and  set  the  tone  for 
the  MRA.  The  first  is  that  “The  MRA  process  shall  be  free  of  political,  budget,  strategic, 
or  mission  prioritization  constraints...”  (Commandant,  2014,  p.  3.F.3.a).  The  MRA 
should  figuratively  be  executed  in  a  vacuum  as  if  only  the  work  exists,  and  the  analyst  is 
determining  for  the  first  time  what  manpower  is  required. 

The  second  notable  guiding  principle  is  “MRD  analysts  shall  identify  and 
categorize  all  work  associated  with  the  OE...  but  shall  only  analyze  the  OE’s  adjudicated 
work  requirements”  (Commandant,  2014,  p.  3.E.3.a).  Work  requirements  that  are  not 
adjudicated  are  not  directed  by  extant  data  resources,  organizational  directives  or 
publications.  An  example  of  work  that  may  not  be  adjudicated  is  an  extra  daily  safety 
patrol  executed  by  a  USCG  station.  This  patrol  is  not  a  requirement,  and  is  above  and 
beyond  what  is  expected  of  the  station.  In  this  example,  it  also  surpasses  what  can 
routinely  be  executed  by  a  single  watch  section,  so  the  Commanding  Officer  directs  an 
additional  boat  crew  to  be  added  to  each  watch  section.  This  increased  patrol  posture 
again  is  not  a  requirement  so  will  not  be  identified  as  work  during  an  analysis.  Therefore, 
the  USCG  station  will  not  receive  additional  manpower  to  execute  the  additional  daily 
safety  patrol.  OE  leadership  should  be  careful  not  to  obligate  itself  to  work  that  cannot  be 
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adjudicated  as  additional  manpower  will  not  be  provided  to  facilitate  the  completion  of 
these  tasks. 

The  third  notable  guiding  principle  is  “MRD  analysts  shall  identify  an  audit  trail 
that  can  be  easily  traced,”  and  the  “MRD  will  reflect  the  minimum  manpower,  minimum 
pay  grade,  and  competency  requirements  necessary  to  perform  the  work”  (Commandant, 
2014,  p.  3.F.3.a).  This  principle  alleviates  bias  by  directing  a  process  with  a  clear 
standard  that  yields  results  that  are  verifiable,  repeatable,  and  defensible. 

Guiding  principles  and  core  assumptions  in  place.  Phase  II  begins  with  the  Data 
Collection  Plan  (DCP).  It  is  a  tool  to  organize  the  data  collection,  and  help  set  the  sponsor 
and  OE’s  expectations.  The  DCP  includes  the  type  of  information  to  be  collected,  the 
method(s)  used  to  collect  the  information,  the  personnel  required  to  support  the 
information  collection,  and  the  associated  logistics.  Information  collection  methods 
include  work  sampling,  operational  audit,  interview,  and  survey.  “The  DCP  is  made  up  of 
a  series  of  tables  that  list  interview  subjects,  extant  data  sources,  electronic  data  sources, 
and  other  sources  of  information  particular  to  the  OE  being  studied”  (Commandant, 
2010a,  p.  3-2). 

The  Work  Matrix,  also  a  series  of  spreadsheets,  is  the  data  repository  for  collected 
work  and  workload  information  during  an  MRA.  It  contains  a  significant  amount  of 
information  about  each  task  including  task  description,  type,  class,  reference,  frequency, 
count,  etc.  The  Work  Matrix  is  the  foundation  for  future  analysis  including  modeling  and 
options  development.  Work  and  workload  can  alternatively  be  recorded  in  an  Operational 
Audit  or  in  Task  Eists. 

Once  the  MRA  team  identifies  work  and  workload,  their  findings  are  adjudicated 
during  the  Work  Adjudication  Conference  (WAC).  This  “is  an  iterative  back-and-fourth 
discussion  between  the  requestor  and  MRA  team”  (Commandant,  2014,  p.  3.E.3.C.4.). 
Gaining  eoneurrence  in  regard  to  the  information  recorded  in  the  Work  Matrix,  and 
subsequently  agreeing  on  the  assignment  of  competencies  and  major  accomplishments  to 
tasks  are  focal  points  of  the  WAC.  Results  from  the  WAC  are  documented  in  a  Work 
Report  that  capture  the  requestor’s,  the  OE’s,  and  the  MRA  team’s  collaborative  efforts. 
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Workload  constraints  and  assumptions  (WCA)  must  also  be  accounted  for  when 
identifying  work  and  workload  information.  Assumptions  and  constraints  influence  how 
work  is  identified,  measured,  and  distributed.  For  example,  a  constraint  may  dictate  a 
specific  rank  to  whom  a  particular  task  should  be  distributed.  The  product  that  captures 
workload  constraints  and  assumptions  as  well  as  total  workload  requirements  is  the  WCA 
Report.  It  is  submitted  during  Phase  II  as  a  follow-up  to  the  Work  Report,  but  the 
information  is  not  applied  until  Phase  III. 

Phase  II  ends  with  the  application  of  allowances.  Allowances  account  for  time 
members  are  at  work  but  not  accomplishing  their  specific  workload.  Allowances  that  may 
be  applied  are  Personal  Fatigue  and  Delay  (PF&D),  Training,  Make  Ready/Put  Away, 
and  Corrective  Maintenance  Ratio  (Commandant,  2014,  p.  3.F.3.C.6.).  For  example,  these 
allowances  account  for  a  member’s  personal  needs,  training,  information  requirements, 
and  preparation  and  clean  up  before  and  after  maintenance,  etc.  Allowances  positively 
contribute  to  the  accuracy  of  determining  manpower  requirements.  They  alleviate 
distributing  more  work,  than  what  can  reasonably  be  achieved,  to  any  one  position. 

5.  Phase  Ill-Human  Resources  System  Alignment 

Phase  III,  Human  Resources  (HR)  System  Alignment,  is  centered  on  modeling  the 
information  collected  in  the  previous  phases  and  yielding  alternative  staffing  options. 
Phase  III  also  includes  an  MRA  Options  Report,  an  MRA  Manpower  Option  Selection 
Meeting,  and  an  MRA  Report.  The  publication  of  the  MRA  Report  ends  Phase  III  and  the 
MRA. 

Until  Phase  III  the  requirements  determination  process  for  fleet  and  shore  is  the 
same.  The  process  diverges  at  modeling.  Fleet  requirements  are  determined  by  the  Navy 
Manpower  Requirements  System  (NMRS),  and  shore  requirements  are  determined  using 
the  Manpower  Determinant  Model  (MDM).  NMRS  “utilities  a  ‘building  block’  process 
wherein  the  categories  of  workload  and  watchstanding  requirements  are  accumulated  and 
processed  to  form  the  minimum  billet  requirements”  (Commandant,  2014,  p.  3.F.4.b.). 
“The  MDM  captures  all  work,  organizes  tasks  by  major  accomplishment,  calculates 
workload,  and  distributes  work  based  on  the  minimum  pay  grade  necessary  to  complete 
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the  work”  (Commandant,  2014,  p.  3.F.4.a.).  Despite  the  different  modeling  methods,  a 
eommon  business  rule  is  that  manpower  is  determine  to  a  minimum. 

Results  of  the  modeling,  namely  alternative  staffing  options,  are  doeumented 
within  an  MRA  Options  Report.  The  MRA  Options  Report  not  only  details  alternative 
staffing  options,  but  also  provides  analysis  in  regard  to  capability  and  capacity  limitations 
and  requirements.  Before  the  MRA  team  makes  the  MRA  Options  Report  available  to  the 
requestor,  it  is  submitted  to  MRD  partners  and  stakeholders  to  confirm  the  viability  of 
each  staffing  option.  Following  partner  and  stakeholder  review,  the  MRA  Options  Report 
is  made  available  to  the  requestor. 

The  MRA  Options  Report  is  discussed  at  length  at  the  Manpower  Option 
Selection  Meeting.  This  meeting  is  the  requestor’s  opportunity  to  discuss  the  different 
staffing  options  with  the  MRA  team,  ask  questions,  and  identify  discrepancies.  Most 
notable  at  this  meeting,  the  requestor  selects  its  preferred  staffing  alternative,  and  it  is  this 
choice  or  MRD  that  is  captured  in  the  MRA  Report.  Upon  submission  of  the  MRA 
Report,  Phase  111  and  the  MRA  process  are  complete. 

Although  the  MRA  process  is  not  complicated,  it  is  lengthy  and  requires  several 
meetings  and  reports.  The  MRA  Phases,  required  meetings  and  reports  are  summarized  in 
Figure  2. 


13 


Phase  1:  Requestor  \ 
Alignment  I 


Alignment  Meeting 


Alignment  Report 


Phase  2:  Mission 
Alignment 


Work  Adjudication 
Meeting 


Data  Collection  Plan 


Work  Matrix 


Phase  3:  HR  System 
Alignment 


Manpower  Option 
Selection  Meeting 


MRA  Options  Report 


MRA  Report 


Key 

=  Meeting 

CD  =  Product/Report 


Figure  2.  MRA  Phases,  required  meetings  and  reports. 


B,  NAVY  MRD 

The  Navy  determines  four  types  of  manpower  requirements;  Fleet,  shore. 
Individuals  Account  (lA),  and  Outside  Navy.  Only  Fleet  and  shore  requirements  will  be 
reviewed  in  this  research.  Regardless  of  the  type  of  manpower  requirement,  the  definition 
is  the  same; 

Manpower  requirements  define  the  number  of  personnel  required  to 
perform  the  Navy’s  work  and  deliver  the  specified  capability.  Each 
manpower  requirement  equates  to  a  specific  manpower  space  which  is 
assigned  qualifiers  that  define  the  duties,  tasks,  and  functions  to  be 
performed  and  the  specific  skills  and  skill  level  required  to  perform  the 
delineated  functions.  (Office  of  the  Chief  of  Naval  Operations,  2007, 

p.  1-1) 

Despite  the  type  of  requirement.  Navy  manpower  requirements  reflect  the 
minimum  quantity  and  quality  of  work  by  occupation  to  meet  mission  requirements. 
“These  two  factors  are  commonly  paired  together  as  ‘quan/qual”’  (Office  of  the  Chief  of 
Naval  Operations,  2007,  p.  2-2).  Quantity  is  the  number  of  manpower  requirements  to 
meet  mission  requirements.  It  is  calculated  using  Navy  Standard  Work  Weeks.  Quality  is 
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the  occupational  knowledge,  skills  and  abilities  that  are  required  to  execute  mission 
requirements.  The  parameters  for  quality  are  found  in  the  Navy  Enlisted  Occupational 
Classification  System  (NEOCS)  described  in  the  Navy  Military  Personnel  Manual 
18068E,  and  the  Navy  Officer  Occupational  Classification  System  (NOOCS)  described  in 
the  Navy  Military  Personnel  Manual  158391. 

1.  Fleet  Requirements 

Elect  manpower  includes  requirements  for  ships,  squadrons  and  other  deployable 
units.  Required  Operational  Capability/Projected  Operating  Environment  (ROC/POE)  is 
the  principal  resource  that  directs  mission  requirements  that  translate  to  work  and 
subsequently  manpower  requirements.  Some  of  the  other  sources  that  influence  Elect 
manpower  requirements  are  Navy  Training  Systems  Plans  and  Activity  Manpower 
Document  (AMD)  Change  Requests. 

The  determination  of  all  Elect  manpower  requirements  is  centralized  at 
NAVMAC.  NAVMAC  (N121)  is  overseen  by  OPNAV  N12,  the  Total  Eorce 
Requirements  Division.  Teams  from  NAVMAC  visit  units  to  collect,  assess,  and  validate 
workload.  Elect  workload  is  dominated  by  watch  standing.  Workload  information, 
specifically  workload  hours,  are  inputted  into  the  Navy  Manpower  Requirements 
Systems,  and  paired  with  occupational  knowledge,  skills,  and  abilities  to  further  quantify 
and  qualify  manpower  requirements.  NMRS  produces  a  recommended  manpower  mix 
based  on  the  determined  and  validated  workload  information.  Next,  workload  and 
manpower  information  is  entered  into  the  Total  Eorce  Manpower  Management  System 
(TEMMS).  TEMMS  is  a  data  repository,  and  “the  single,  authoritative  database  for  Total 
Eorce  manpower  requirements,  and  active  duty  MPN/RPN  [Military  Personnel 
Navy/Reserve  Personnel  Navy]  manpower  authorizations  and  end  strength”  (Office  of  the 
Chief  of  Naval  Operations,  2007,  p.  B-18). 

The  Elect  Manpower  Requirements  Determination  Process  yields  one  of  three 
documents  at  the  conclusion  of  the  process.  The  type  of  document  produced  depends  on 
the  unit  evaluated.  The  potential  documents  are:  the  Elect  Manpower  Document  (EMD), 
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the  Squadron  Manpower  Document  (SQMD),  or  the  Ship  Manpower  Document  (SMD). 
These  documents  capture  fleet  manpower  requirements  by  unit  class. 

Once  programmed  funding  is  applied  to  Fleet  Manpower  Requirements  an  AMD 
is  produced.  An  AMD  is  “the  qualitative  and  quantitative  expression  of  manpower 
requirements  (military,  civilian,  and  contractor)  and  authorizations  (military)  allocated  to 
a  naval  activity  to  perform  the  assigned  MFTs  [Missions,  Functions,  and  Tasks]  or 
ROC/POE”  (Navy  Manpower  Analysis  Center,  2000,  p.  M-1).  As  the  definition  suggests, 
this  document  differs  from  the  FMD,  SQMD,  and  SMD  in  that  it  captures  manpower 
requirements  and  authorizations.  The  AMD  reports  manpower  requirements  by  Unit 
Identification  Code  (UIC)  and  notates  their  funded  or  unfunded  status.  The  Fleet 
Manpower  Requirements  Determination  Process  is  summarized  in  Figure  3. 
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Figure  3.  Navy  Fleet  Manpower  Requirements  (from  Hatch,  2013). 
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2,  Shore  Requirements 

Shore  manpower  requirements  inelude  aetivities  that  are  not  governed  by 
ROC/POE,  and  are  not  lA  or  Outside  Navy  requirements.  “Navy  shore  manpower 
requirements  shall  be  based  on  directed  Missions,  Functions,  and  Tasks  (MFTs)”  (Office 
of  the  Chief  of  Naval  Operations,  2007,  p.  2-2).  Shore  manpower  requirements  are  also 
influenced  by  AMD  Change  Requests  and  PWSs. 

The  Shore  Manpower  Requirements  Determination  Process  (SMRDP)  is 
decentralized.  34  individual  Budget  Submitting  Offices  (BSO)  determine  manpower 
requirements  for  their  respective  constituency.  BSOs  are  made  up  of  military,  civilian, 
and  contract  personnel. 

As  a  result  of  the  decentralization  of  the  SMRDP  from  BSO  to  BSO  the  process  is 
not  standardized.  Similar  to  NAVMAC’s  analysts,  BSO  personnel  visit  various  units  to 
collect,  assess,  and  validate  workload,  however,  workload  measurement  methods  vary. 
Two  popular  methods  are  Op  Audit  and  Work  Sampling,  which  are  based  in  statistics. 
“Op  Audit  is  a  work  measurement  tool  in  where  work-hours  required  to  accomplish 
defined  categories,  tasks,  and  sub  tasks  of  work  within  a  work  center/organizational 
component  are  derived  by  identification  and  summation  of  frequencies  of  occurrence 
multiplied  by  their  unit  times”  (Navy  Manpower  Analysis  Center,  2000,  p.  5-1).  Work 
sampling  is  based  on  the  notion  that  random  samples  from  a  large  population  will  reflect 
the  characteristics  of  not  only  the  sample  but  the  population. 

Regardless  of  the  workload  measurement  method  used,  results  are  inputted  into 
TFMMS.  Since  BSOs  are  decentralized  and  TFMMS  is  the  repository  for  significant  data 
that  informs  resource  decisions,  not  all  BSOs  have  the  direct  capability  to  change 
TFMMS.  Instead  they  have  access  to  the  TFFMS  Micro  Manpower  Change  Application 
(TMMCA)  which  feeds  TFFMS. 

The  Shore  Manpower  Requirements  Determination  Process  yields  a  Statement  of 
Manpower  Requirements  (SMR)  during  peacetime  and  a  Mobilization  Statement  of 
Manpower  Requirements  (MSMR)  for  wartime. 
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In  general  terms,  the  analyst  develops  the  SMR/MSMR  by  ealeulating 
quantitative  and  qualitative  manpower  requirements  based  on  work 
measurement  and  methods  improvement  data.  The  SMR/MSMR  will 
refleet  the  skill  and  manpower  mix  requirements  needed  to  support  the 
activity’s  directed  MFTs  and  associated  workload.  (Navy  Manpower 
Analysis  Center,  2000,  p.  1-5) 

The  SMR  and  the  MSMR  reflect  requirements  only.  The  AMD  follows  the  associated 
SMR  and  the  MSMR.  Similar  to  the  Fleet  Manpower  Requirements  Determination 
Process,  the  AMD  reflects  requirements  and  authorizations.  The  SMRDP  is  summarized 
in  Figure  4. 


SHORE  MANPOWER  REQUIREMENTS 


Input  Throughput  Results 

Outputs 


Figure  4.  Navy  Shore  Manpower  Requirements  (from  Hatch,  2013). 


C.  CHAPTER  SUMMARY 

The  USCG  and  Navy  share  the  objective  to  get  the  right  people,  to  the  right 
places,  at  the  right  times,  with  the  right  skills.  Accurate  manpower  requirements  reflect 
the  standard  for  a  ready  force,  and  safe  and  effective  mission  execution.  In  both  services 
mission  requirements  drive  manpower  requirements,  and  manpower  requirements  are 
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determined  to  a  minimum  quantity,  to  minimum  pay  grades,  and  to  minimum 
eompeteneies. 

The  USCG  and  Navy  proeesses  for  determining  manpower  requirements  are  also 
similar.  In  faet,  the  USCG  has  adopted  many  Navy  proeesses  as  its  own.  For  example,  the 
USCG  uses  NMRS  to  model  Fleet  Manpower  Requirements.  The  USCG  is  able  to  use 
Navy  produets  beeause  the  nature  of  work  between  the  services  is  comparable. 

As  similar  as  the  USCG  and  Navy  processes  for  determining  manpower 
requirements  are  some  fundamental  differences  exist.  For  example,  the  Manpower 
Requirements  Determination  Division,  CG-1B4  is  the  authority  for  Fleet  and  shore 
USCG  MRDs,  whereas  the  Navy’s  organization  is  significantly  decentralized.  NAVMAC 
is  the  authority  for  Fleet  manpower  requirements,  and  34  individual  BSOs  are  the 
authorities  for  shore  manpower  requirements. 

Meeting  twenty-first  century  challenges  start  with  accurate  manpower 
requirements  determination.  There  is  benefit  to  the  USCG  and  the  Navy  remaining 
appraised  of  each  service’s  best  practices  and  lessons  learned.  Exchange  between  the 
services  will  contribute  to  optimizing  their  respective  manpower  requirements 
determination  processes. 
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III.  DESCRIPTION  OF  METHOD  AND  ANALYSIS 


The  United  States  Coast  Guard  (USCG)  either  eompletes  Manpower 
Requirements  Analyses  (MRA)  organieally  with  Aetive  Duty  and  civilian  members  using 
a  series  of  spreadsheets,  or  contracts  them  out.  This  is  inefficient,  because  it  is  costly, 
untimely,  lacking  transparency  and  standardization,  etc.  The  vision  to  improve  the 
Manpower  Requirements  Process  includes  a  new  or  revised  Manpower  Requirement 
Determination  Automated  Information  System  (MRD  AIS)  with  data  repository, 
optimization,  and  modeling  and  simulation  capabilities. 

The  foundation  of  a  MRD  AIS  and  many  process  automation  systems  is  an  entity- 
relationship  diagram  (ERD)  and  a  subsequent  relational  database.  The  relational  database 
is  the  data  repository,  however,  queries  can  be  run  within  the  relational  database  that 
produce  tables  similar  to  tables  found  in  MRAs.  The  query  capability  is  a  source  of 
efficiency,  and  will  alleviate  Manpower  Requirements  Determination  (MRD)  team 
members  from  manually  drafting  these  tables. 

The  scope  of  this  project  includes  the  ERD,  a  relational  database,  and  the 
verification  and  validation  of  the  ERD  via  testing  the  relational  database.  A  description  of 
these  products  are  found  in  the  following  paragraphs.  Overall,  this  project  demonstrates 
fundamentally  the  efficiency  that  may  be  gained  by  implementing  this  or  a  similar 
relational  database. 

A,  MODELED  FACTORS  THAT  CONTRIBUTE  TO  DETERMINING 

MANPOWER  REQUIREMENTS 

Accurate  manpower  requirements  determination  relies  on  the  thorough 
identification  and  consideration  of  the  factors  that  influence  manpower  requirements.  Eor 
example,  although  members  are  at  work  for  approximately  8-12  hours,  they  do  not 
complete  8-12  hours’  worth  of  work.  Aside  from  at  least  one  break  for  a  meal  during  that 
time,  members  need  breaks  to  mitigate  fatigue,  use  the  bathroom,  etc.  Therefore,  it  is 
important  to  determine  how  much  time  members  actually  spend  working  while  they  are 
at  work.  Time  away  from  work  as  a  result  of  dental  and  medical  appointments,  drills. 
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physical  fitness,  training,  etc.,  also  need  to  be  eonsidered.  If  these  interruptions  are  not 
aceounted  for  with  “allowanees,”  an  entity  in  the  ERD,  more  work  will  get  distributed  to 
a  member  than  what  he  or  she  ean  aetually  eomplete.  This  example  illustrates  that  failing 
to  be  thorough  and  specitio  in  identifying  factors  that  contribute  to  determining 
manpower  requirements  eould  signitieantly  skew  an  MRD,  and  underestimate  the 
quantity  of  members  required  to  eomplete  a  preseribed  amount  of  work  or  mission. 

Ineomplete  identifieation  of  faetors  that  influenee  manpower  requirements  not 
only  impaet  the  quantity  of  members  determined  but  the  quality  of  members  determined 
as  well.  As  deseribed  in  the  Navy  MRD  seetion,  this  is  quan/qual,  also  known  as  “fill  and 
fit.”  Quantity  is  synonymous  for  fill,  and  quality  is  synonymous  for  fit.  An  example  for 
fit  is  the  eonsideration  of  eompeteneies.  If  a  small  boat  station  has  boats  with  outboard 
engines,  and  the  only  assigned  Maehinery  Teehnieians  assigned  have  not  been  to  the 
outboard  engine  school  and  only  have  experienee  with  inboard  engines,  this  degrades  the 
unit’s  assets’  operational  availability  and  ultimately  the  unit’s  overall  readiness. 

Thorough  identifieation  of  faetors  that  influenee  the  quantity  and  quality  of 
manpower  is  imperative  to  aeeurate  MRAs  and  MRDs.  To  be  as  thorough  as  possible  in 
determining  these  faetors,  the  USCG  Staffing  Logic  and  Manpower  Requirements 
(SLMR)  Manuals,  Volumes  I-IV;  assoeiated  job  aids  and  templates,  and  recent  MRAs 
for  the  following  organizational  elements:  Judge  Advoeate  General  (JAG)  Program, 
Maritime  Foree  Protection  Unit  (MFPU),  Regional  Dive  Loeker  Paeifie,  and  WTGB  140’ 
(Bay)  Class  Icebreaking  Harbor  Tug  were  reviewed. 

To  help  identify  the  factors  that  influence  manpower  requirements,  nouns  that 
deseribe  people,  work  or  workload,  and  organization  were  the  foeal  point.  In  regard  to 
people,  nouns  and  adjectives  ineluding  but  not  limited  to  eompetency,  position,  rank, 
rate,  and  work  week  availability  were  brainstormed.  For  work;  allowanees,  assumptions, 
eonstraints,  major  aeeomplishments,  and  tasks  were  eompiled.  For  organization; 
department,  division,  seetion,  and  team  was  reeorded.  A  eomplete  list  of  faetors  ean  be 
found  in  Appendix  A. 
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A  significant  challenge  in  identifying  the  factors  that  contribute  to  determining 
manpower  requirements  was  non-standard  terminology.  Language  in  the  MRAs  deviated 
from  the  language  used  in  the  SLMR  Manuals  (note;  Volumes  II-IV  were  in  draft  form), 
and  further  language  in  the  MRAs  deviated  from  one  another.  Therefore,  it  was  difficult 
to  determine  what  faetors  were  synonymous  with  one  another,  and  what  faetors  were 
different  enough  that  they  should  have  a  unique  entity  or  attribute.  A  eatalyst  of  the  non¬ 
standard  terminology  may  be  that  different  sourees,  two  different  eontraetors  or  the 
USCG,  whieh  eompleted  the  reviewed  MRAs. 

A  partieularly  interesting  example  of  non-standard  terminology  is  the  use  of 
“task”  and  “work  item,”  as  well  as  “eategory”  and  “major  aeeomplishment.”  The  impetus 
for  the  USCG  to  group  tasks  into  major  aeeomplishments  was  derived  from  the  Navy 
Total  Force  Manpower  Requirements  Handbook  (Commandant,  2014).  The  handbook, 
however,  uses  the  term  “eategory”  while  the  USCG  uses  “major  aeeomplishment.”  Based 
on  informal  eommunications  with  the  USCG  MRD  Division,  the  USCG  uses  major 
aeeomplishment  to  standardize  its  language  with  USCG  Human  Performanee  Teehnology 
(HPT)  divisions  that  use  terminology  consistent  with  the  Aeeomplishment  Based 
Currieulum  Development  (ABCD)  system  founded  by  Joe  Harless.  That  said,  it  appears 
standardization  with  HPT  divisions  stopped  short,  beeause  the  USCG  is  using  work  item 
viee  task.  This  is  eontradietory  as  task  is  eonsistent,  and  work  item  is  not  eonsistent  with 
the  ABCD  system.  Further  exaeerbating  the  issue  is  that  eategory  and  major 
aeeomplishment  are  sometimes  used  synonymously,  and  sometimes  eategory  is  used  in 
other  eontexts.  Throughout  this  projeet,  major  aeeomplishment  and  task  are  used 
eonsistently  and  are  distinct  from  any  other  entities  and  attributes. 

B,  ENTITY-RELATIONSHIP  MODEL 

The  ERD  was  drafted  using  the  proeess  outlined  in  Design  of  Enterprise  Systems  - 
Theory,  Architecture,  and  Methods  as  a  preeursor  to  the  relational  diagram  (Giaehetti, 
2010).  A  complete  draft  of  the  ERD  is  loeated  in  Appendix  B.  Mierosoft  Visio  2010  was 
used  as  the  tool  to  design  the  ERD.  The  program  is  user  friendly.  The  most  helpful 
feature  was  that  when  relationships  were  established  between  two  entities,  the  primary 
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key  would  automatically  migrant  from  the  parent  entity  to  the  child  entity  as  a  foreign 
key.  The  most  challenging  feature  was  changing  the  crow’s  foot  notation.  Namely  once 
two  entities  were  related  and  the  relationship  was  determined  to  be  incorrect,  it  was 
difficult  to  edit  the  relationship  type.  Later  when  entering  the  model  in  access,  the 
difficulty  editing  the  relationship  type  was  often  an  indication  that  an  associative  entity 
was  required. 

Although  relationships,  not  order,  are  what  drive  an  ERD,  the  ERD  was  drafted 
sequentially  following  the  MRA  process.  The  process  started  with  the  entity.  Requestor, 
and  finished  with  the  entity.  Option.  While  the  ERD  was  drafted,  nouns  describing 
people,  work  or  workload,  and  organization  continued  to  be  the  focal  points.  In  the 
following  paragraphs,  the  ERD  is  discussed  in  greater  detail  and  references  are  made  to 
the  ERD  by  entity. 

Entities  that  provide  background  information  including  the  MRA  request,  the 
MRA  team,  and  the  MRA  are  shown  in  Eigure  5.  The  entities.  Requestor  and 
MRARequest,  and  their  respective  attributes  resemble  the  information  found  in  USCG 
form  5310,  The  MRA  Request.  Not  only  is  this  information  important,  but  the  existence 
of  these  entities  and  attributes  will  contribute  to  transitioning  the  MRA  request  process 
from  a  manual  to  an  electronic  process. 
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Figure  5.  Background  Information  including  MRA,  MRARequest,  and 

MRATeam 


The  ERD  reflects  sources  of  task  and  workload  information.  In  this  model,  data  is 
collected  from  reference  documents  including  but  not  limited  to  Department  of 
Homeland  Security  (DHS),  USCG,  and  program  documents,  and  via  interviews  and 
surveys  as  shown  in  Figure  6.  Interview  and  survey  information  is  found  in  a  series  of 
entities  including  Interview,  InterviewQuestion,  InterviewAnswer,  Survey, 
SurveyQuestion,  SurveyAnswer,  and  SurveyRespondent.  Having  a  repository  of 
interview  and  survey  questions  will  alleviate  the  MRA  team  from  drafting  original 
questions  for  each  MRA,  yet  provide  the  MRA  team  flexibility  to  tailor  the  interviews 
and  surveys  to  different  organizational  elements.  Having  a  repository  of  interview  and 
survey  answers  will  provide  invaluable,  historical  perspective  that  may  yield  broader 
manpower  requirement  conclusions. 
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Figure  6.  Sources  of  Task  and  Workload  Information 


People  information  is  found  in  the  Position,  Rate,  and  Rank  entities  as  shown  in 
Figure  7.  The  Position  entity  describes  the  required  positions  based  on  the  MRA.  Its 
primary  key  is  PositionID.  Position  and  PositionID  are  separate  and  distinct  from 
positions  on  the  Personnel  Allowance  List  (PAL)  and  its  respective  position  numbers. 
Within  the  entity.  Position,  there  is  a  binary  attribute,  PresenceOnPAL.  If  a  similar 
position  is  determined  to  be  required  as  there  already  exists  on  the  PAL,  then  the  binary 
response  recorded  in  PresenceOnPAL  is  yes.  If  the  binary  response  is  yes,  then  the 
PALPositionNumber  will  be  recorded  to  facilitate  a  comparison  between  what  is  required 
and  what  exists. 
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Figure  7.  People  Information 


Work  or  workload  information  is  found  in  the  ERD  in  the  Task,  Competency, 
Workload,  MajorAccomplishment,  Constraint,  Assumption,  and  WorkWeekAvailability 
entities  as  shown  in  Figure  8.  As  you  would  expect,  the  Task  entity  appears  to  be  the 
central  entity  of  the  ERD.  Originally,  the  ERD  was  drafted  with  the  workload  attributes 
as  part  of  the  Task  entity  so  it  was  previously  even  more  dominate  than  it  is  now. 
Workload  attributes  were  separated  from  the  Task  entity  to  make  the  spreadsheets  more 
manageable. 
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Figure  8.  Work  and  Workload  Information 


Per  SLMR  manual,  Volume  III,  competencies  are  supposed  to  be  related  to  major 
accomplishments  (Commandant,  2010a,  p.  3-26).  A  relationship  was  drafted  between  the 
Task  and  Competency  entities  vice  between  the  MajorAccomplishment  and  Competency 
entities  as  shown  in  Figure  9.  This  was  done  because  not  ah  task(s)  rise  to  the  level  of  a 
major  accomplishment,  but  a  particular  competency  or  competencies  may  still  be 
required  to  complete  the  task(s).  Creating  a  relationship  between  the  Task  and 


28 


Competency  entities  will  more  thoroughly  identify  the  competencies  required  to  complete 
tasks  and  major  accomplishments. 


Figure  9.  Competency  Relationship 


In  the  ERD,  there  is  an  Assumption  entity  and  a  GeneralAssumption  entity.  To 
alleviate  any  confusion  between  the  two  entities  a  short  description  follows.  The 
Assumption  entity  applies  to  people  and  work  or  workload,  and  is  related  to  the  Position 
and  Task  entities  as  shown  in  Figure  8.  The  Assumption  entity  records  published 
standards  that  influence  the  way  and  how  much  work  is  distributed  to  positions.  The 
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GeneralAssumption  entity  provides  baekground  information,  and  is  related  to  the  MRA 
entity  as  shown  in  Figure  10.  The  GeneralAssumption  entity  influenees  the  overall 
exeeution  of  the  MRA. 
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Figure  10.  GeneralAssumption  Entity 


Organization  information  is  found  in  the  ERD  in  the  OE,  WorkCenter,  and  Option 
entities.  OE  is  short  for  organizational  element.  An  organizational  element  may  be  a  unit 
or  a  portion  of  a  unit.  Work  eenters  make  up  OEs,  and  OEs  are  colleetions  of 
departments,  divisions,  branehes,  etc.  The  entity,  WorkCenter  is  purposefully  general.  It 
should  accommodate  any  OE’s  organization.  Any  ambiguity  should  be  resolved  with  the 
attribute,  WorkCenterDescription.  The  OE  and  WorkCenter  entities  are  connected 
through  the  Task  entity  as  shown  in  Eigure  1 1 . 
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Figure  1 1 .  OE  WorkCenter  Relationship 

The  Option  entity  catalogs  each  manpower  alternative.  In  an  earlier  ERD  draft,  an 
MRD  entity  existed,  however,  it  was  deleted  because  it  did  not  host  much  information. 
Instead,  MRD  was  added  as  an  attribute  to  the  Option  entity  as  shown  in  Eigure  12.  The 
MRD  attribute  is  binary.  One  of  the  options  will  be  the  MRD,  and  a  simple  binary  data 
point  will  communicate  which  option  is  the  MRD  clearly. 
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Figure  12.  Option  Entity 

C.  RELATIONAL  DATABASE 

Establishing  an  ERD  ahead  of  the  relational  database  made  creating  the  relational 
database  easy.  The  relational  database  was  drafted  in  Microsoft  Access  2013.  The 
program  is  easy  to  use,  however,  not  as  user  friendly  as  Microsoft  Visio  2010.  Creating 
tables  and  running  queries,  however,  were  particularly  simple. 

The  most  inconvenient  features  of  Microsoft  Access  2013  were  key  migration, 
establishing  relationships,  and  print  margins.  Unlike  Microsoft  Visio  2010,  primary  keys 
did  not  automatically  migrate  as  foreign  keys  from  parent  to  child  entities.  Eoreign  keys 
needed  to  be  manually  added  in  Microsoft  Access  2013.  Also  relationships  had  to  be 
deliberately  made.  A  primary  key  needed  to  be  specihcahy  linked  to  another  primary  or 
foreign  key  for  a  relationship  to  be  established,  whereas  in  Microsoft  Visio  2010,  the 
relationship  line  only  needed  to  be  dragged  into  the  entities  in  general  for  the  linkage  to 
be  made.  These  shortcoming  with  Microsoft  Access  2013  made  the  ERD  particularly 
valuable  as  a  guide  to  accurately  building  the  relational  database.  The  last  inconvenience 
managed  with  Microsoft  Access  2013  was  that  the  print  margins  were  not  visible  on  the 
relationship  tab  or  the  Relationship  Report,  and  a  tool  did  not  exist  to  zoom  in  or  out  of 
these  screens  which  made  viewing  the  relational  database  in  its  entirety  impossible. 

The  relational  database  was  built  in  three  steps:  created  tables  or  entities, 
established  relationships,  and  inputted  data.  Creating  the  entities  was  easy.  Establishing 
the  relationships  were  more  difficult.  Several  error  messages  populated  the  computer 
screen  during  the  process.  Most  commonly,  the  error  messages  were  resolved  by  editing 
the  data  type  of  the  primary  or  foreign  key,  or  by  adding  an  associative  entity.  Primary 
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and  foreign  keys  need  to  have  the  same  data  type  in  order  to  establish  a  relationship 
between  them.  Notable,  Mierosoft  Visio  2010  has  a  much  more  extensive  menu  of  data 
types  than  Microsoft  Access  2013.  Unlike  the  primary  and  foreign  keys  and  the 
relationships,  the  data  types  do  not  replicate  exactly  from  Microsoft  Visio  2010  to 
Microsoft  Access  2013.  Adding  an  associative  entity  resolved  specifically  the 
indeterminate  relationship  error  message. 

Data  type  selection  was  a  little  tedious.  Early  on,  AutoNumber  was  used  for  many 
of  the  artificial  primary  keys.  Two  issues  were  discovered  in  doing  this.  First,  Microsoft 
Access  2013  only  permitted  one  attribute  per  entity  to  have  an  AutoNumber  data  type. 
This  was  problematic  as  primary  keys  migrant,  and  often  migrated  to  entities  that  already 
had  AutoNumber  data  type  attributes.  Next,  AutoNumber  generated  a  single,  non-unique 
numbering  scheme:  one,  two,  three,  four,  etc.  This  was  not  ideal  because  if  many 
attributes  had  an  AutoNumber  data  type  then  their  numbering  scheme  would  be  identical 
and  eventually  confusing  when  synthesizing  data.  Ultimately  the  Short  Text  data  type 
was  the  default  data  type,  because  voluminous  alphanumeric  information  was  inputted. 
The  Number  data  type  did  not  allow  any  alpha  characters. 

As  my  last  step  prior  to  testing,  data  was  inputted.  Data  from  the  Regional  Dive 
Locker  Pacific  and  the  WTGB  140’  (Bay)  Class  Icebreaking  Harbor  Tug  MRAs  was 
used.  Some  made-up  information  was  also  inputted.  Specifically  the  MRA  data  helped  to 
validate  that  the  identification  of  entities  and  attributes  was  thorough.  The  compilation  of 
data  is  not  intended  to  yield  any  specific  result,  but  merely  exists  to  facilitate  test  and 
evaluation  of  the  relational  database. 

Inputting  data  to  the  relational  database  served  as  a  premature  evaluation.  It 
helped  me  identify  areas  where  data  was  lacking  and  redundancies.  The  datasheet  view 
was  easy  to  navigate,  and  observe  where  edits  were  required.  For  example  in  the 
Constraint  entity,  each  type  of  constraint  was  listed  as  an  attribute  but  during  data  entry 
edited  to  a  single  attribute,  ConstraintType. 
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D,  DESCRIPTION  OF  VERIFICATION  AND  VALIDATION 


The  objective  of  this  project  was  to  build  a  data  repository,  and  to  be  able  to 
summarize  the  data  within  the  repository  in  reports  and  spreadsheets  similar  to  the 
products  in  MRA  reports.  The  relational  database  was  tested  using  queries.  Specifically, 
the  MFPU  MRA  Report  was  reviewed,  and  similar  reports  were  successfully  produced. 
On  average,  the  relational  database  can  produce  approximately  70%  of  the  spreadsheets 
and  reports  found  in  MRAs.  A  combination  of  real  and  fictitious  data  was  used  in  testing, 
so  the  results  reflected  in  the  generated  spreadsheets  and  reports  below  are  fictitious. 

The  MFPU  MRA  Report  listed  the  project’s  assumptions  as  shown  in  Figure  13. 
This  product  was  replicated  with  simulated  data  as  shown  in  Figure  14.  Figure  14. 
specifically  demonstrates  the  repository  capability  of  the  relational  database  in  that  it 
reflects  all  project  assumptions  entered  in  the  relational  database  by  MRAID  and  OF 
name. 


6.1  Project  Assumptions 

The  following  assumptions  were  integrated  into  the  analysis: 

•  The  higher  the  degree  of  anal\lical  rigor,  the  more  accurate  the  MRD;  the  more  accurate 
the  MRD,  the  better  the  MRD  helps  Sponsors  manage  resources,  requirements,  and  risk. 

•  The  MRA  Sponsor  will  provide  a  Sponsor’s  Representative  that  will  be  readily  available 
to  facilitate  all  aspects  of  the  MRA. 

•  The  MRA  Sponsor  will  provide  extant  data  described  in  the  Sponsor’s  Guidebook  and 
identified  in  the  Alignment  Meeting  or  by  SMEs. 

•  The  MRA  Team  will  have  reasonable  access  to  SMEs,  APs,  and  other  key  persoimel,  and 
will  coordinate  requests,  meetings,  briefs,  conferences,  and  inteniews  with  the  MRA 
Sponsor. 

•  Manpower  workload  demand  for  an  OE  is  determined  by  mission  requirements,  operating 
environment,  asset  configuration,  and  equipment,  and  is  expressed  as  average  man- 
hoursweek. 

•  Budgetar\'  constraints,  allowances  for  personnel  in  a  transient  leave  status,  inadequately 
tramed  personnel,  habitabiliw  constramts,  and  abnormal  operational  demands  resulting 
from  militaiy  contingencies  and  emergencies  are  excluded.  In  essence,  the  MFPU  is 
fully  funded,  all  MFPU  staff  are  full-trained  and  fully-qualified  when  they  arrive  for  the 
billet  they  are  assigned  eind  the  MFPU  will  operate  under  normal  circumsteinces. 

Figure  13.  MFPU  MRA  Report  Project  Assumptions 
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MRAID  -t 
kiRAOOl 

OEName 

Bay  Class  Icebreaking  HarborTug 

AssumptionDescription 

The  technical  estimates  of  time  required  to  accomplish  work,  broken  down  intc 

MRAOOl 

Bay  Class  Icebreaking  HarborTug 

Unless  otherwise  indictated,  only  work  normally  assigned  and  completed  by  W 

MRAOOl 

Bay  Class  Icebreaking  HarborTug 

All  relevent  extant  data  and  information  was  presented  to  the  MRD  analysts. 

MRAOOl 

Bay  Class  Icebreaking  Harbor  Tug 

The  WTGB  world  of  work  is  determined  by  its  mission  requirements. 

MRAOOl 

Bay  Class  Icebreaking  Harbor  T ug 

WTGB  missions  will  not  change  in  the  foreseeable  future. 

MRA002 

Regional  Dive  Locker  Pacific 

The  technical  estimates  of  time  required  to  accomplish  work,  broken  down  intc 

MRA002 

Regional  Dive  Locker  Pacific 

Unless  otherwise  indictated,  only  work  normally  assigned  and  completed  by  W 

MRA002 

Regional  Dive  Locker  Pacific 

All  relevent  extant  data  and  information  was  presented  to  the  MRD  analysts. 

MRA002 

Regional  Dive  Locker  Pacific 

The  WTGB  world  of  work  is  determined  by  its  mission  requirements. 

MRA002 

Regional  Dive  Locker  Pacific 

WTGB  missions  will  not  change  in  the  foreseeable  future. 

MRA003 

Maritime  Force  Protection  Unit 

The  technical  estimates  of  time  required  to  accomplish  work,  broken  down  intc 

MRA003 

Maritime  Force  Protection  Unit 

Unless  otherwise  indictated,  only  work  normally  assigned  and  completed  by  W 

MRA003 

Maritime  Force  Protection  Unit 

All  relevent  extant  data  and  information  was  presented  to  the  MRD  analysts. 

MRA003 

Maritime  Force  Protection  Unit 

The  WTGB  world  of  work  is  determined  by  its  mission  requirements. 

MRA003 

Maritime  Force  Protection  Unit 

WTGB  missions  will  not  change  in  the  foreseeable  future. 

Figure  14.  Relational  Database  Assumption  Output 


Finished  workload  is  computed  using  the  equation,  workload  finished  (WLp)  = 
workload  computed  (WLc)  x  workload  multiplier  (WLm).  These  calculations  are 
typically  performed  within  the  Work  Matrix  for  an  MRA.  The  relational  database, 
however,  has  the  capability  to  store  all  the  required  data  and  then  with  the  application  of 
code  perform  necessary  mathematical  computations.  Although  writing  code  was  outside 
the  scope  of  this  project,  all  the  required  data  is  available  in  the  relational  database  as 
shown  in  Figure  15.  For  the  purposes  of  visual  representation,  WLp  was  manually 
calculated. 


WorkloadComputed  » 

WorkloadMultiplier 

»  WorkloadFinished  » 

1.13 

23.4 

1.99 

1.13 

2.2 

20.6 

1.13 

23.4 

11.3 

1.13 

12,8 

1.99 

1.13 

2.2 

* 

Figure  15.  Relational  Database  Workload  Finished  Data 


The  MFPU  MRA  Report  summarized  the  competencies  used  in  the  MRA  as 
shown  in  Figure  16.  The  summary  was  imitated  with  simulated  data  as  shown  in  Figure 
17. 
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Competency 

Id 

Competency 

Type 

Competency 

Title 

Competency  Description 

YNADM 

Personnel 

Administrative 

Specialist 

Demonstrates  knowledge  of  USCG  administrative 
policies,  procedures,  and  correspondence 

GM02 

Weapons 

Armorer 

The  GM02  Armorer  Competency  will  authorize 
members  a  higher  degree  of  maintenance 
responsibility  by  allowing  them  to  repair  small  arms 
beyond  the  operator  level. 

SPCSVBCM 

Boat  Ops 

BCM  SPC  SV 

BCM  safely  perform  their  duties  under  the 
supervision  of  a  COXN.  They  stand  helm,  lookout, 
towing  watches,  and  anchor  watch.  They  also  rig 
towing  and  mooring  lines,  act  as  the  surface 
swimmer,  administer  first  aid,  and  operate  damage 
control  equipment.  They  have  knowledge  of 
general  boat  operations  and  the  local  operating 
area. 

CRWSPC 

Boat  Ops 

BCM  SPC-LE 

Crewmembers  safely  perform  their  duties  under 
the  supervision  of  a  coxswain  They  stand  helm, 
lookout,  towing  watches,  and  anchor  watch.  They 
also  rig  towing  and  mooring  lines,  act  as  the 
surface  swimmer,  administer  first  aid,  and  operate 
damage  control  equipment.  They  have  knowledge 
of  general  boat  operations  and  the  local  operating 
area. 

Figure  16.  MFPU  MRA  Report  Competency  List 


CompetencyCode  • 

CompetencyType  -  CompetencyTitle  CompetencyDescription 

Afloat  Operations  CMPLUS  Maintenance  501753  CMPLUS  Maintenance 

|lAn'GB 001 

WTGB_002 

Afloat  Operations  Team  Coordination  Training-Cutter  OPS  500686  Team  Coordination  Training-Cut 

WTGB_003 

Afloat  Operations  ATON  Deck  Supervisor  230015  ATON  Deck  Supervisor 

WTGB_004 

Afloat  Operations  Minor  Aids  Maintenance  500622  Minor  Aids  Maintenance 

Figure  17.  Relational  Database  Competency  Output 


The  capability  to  compare  manpower  requirements  as  determined  by  an  MRA  and 
current  manning  informs  the  drafting  of  options  toward  the  end  of  an  MRA.  The  MFPU 
MRA  report  made  such  a  comparison  as  shown  in  Figure  18.  The  comparison  was 
replicated  with  simulated  data  as  shown  in  Figure  19.  however,  a  binary  attribute, 
PresenceOnPAL  was  engineered  to  communicate  whether  the  position  already  existed  on 
the  PAL  or  if  it  represented  a  gap.  If  the  position  exists  on  the  PAL,  the  position  number 
is  found  adjacent  to  the  binary  attribute. 
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MFPU  PAL  versus  MRD  Comparison 


Org  Element 

MFPU  PAL 

B.ANGOR  MRD 

Kings  Bav 
MRD  ' 

PAL  Position  Title 

Rank 

Qt> 

MRD  Position 
Title 

Rank 

Qtv 

Rank 

Qt> 

COMAL4ND 

COMXL4KDING 

OFFICER 

CDR 

1 

Commanding 

Officer 

CDR 

1 

CDR 

1 

EXECUTTVE 

OFFICER 

LCDR 

1 

Executive 

Officer 

LCDR 

1 

LCDR 

1 

Sn-XTRE-ADGE 
CMD  CHIEF 

POCM 

1 

Command 
Master  Chief 

POCM 

1 

POCM 

1 

Figure  18.  MFPU  MRA  Report  PAL  vs.  MRD  Comparison 


WorkCenterName 

*  PositionID 

WTGB-BMl 

PositionTitle 

Deck  Division  Head 

PresenceOnPAL 

0 

»  PALPositionNumber  » 

1234567 

Boat  Division 

WTGB-BM2 

Assistant  Navigator 

□ 

Boat  Division 

WTGB-BM3 

Deck  Division  Lead  Petty  Officer 

0 

3456789 

Boat  Division 

WTGB-BMC 

Operations  Department  Head/Navigator 

0 

4567891 

Boat  Division 

WTGB  -  SA/SN 

Deck  Division 

0 

5678912 

Figure  19.  Relational  Database  PAL  vs.  MRA  Comparison 


E.  CHAPTER  SUMMARY 

This  evolution  eonfirms  that  the  implementation  of  a  relational  database  would 
yield  efficiency  in  manpower  requirements  determination.  Critical  in  the  development 
process  is  the  draft  of  an  ERD.  The  ERD  is  an  invaluable  guide  to  building  the  relational 
database.  That  said,  test  and  evaluation  of  the  relational  database  begins  almost 
immediately.  Microsoft  Access  2013  sends  error  messages  when  establishing 
relationships,  inputting  data,  and  running  queries,  so  the  opportunity  exists  throughout 
development  to  continually  improve  the  relational  database.  It  is  an  iterative  process. 
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IV.  SUMMARY,  CONCLUSIONS  AND 
RECOMMENDATIONS 


A,  SUMMARY 

The  United  States  Coast  Guard  (USCG)  executes  1 1  missions  around  the  clock 
and  the  world,  and  in  varying  threat  and  weather  conditions  dictating  an  agile  and 
responsive  workforce.  Therefore,  determining  manpower  requirements  and  getting  the 
right  people,  in  the  right  places,  at  the  right  times,  with  the  right  skills  is  an  ongoing  and 
complex  process.  Too  few  or  underqualified  people  may  adversely  impact  safety, 
readiness,  and  mission  execution.  Too  many  or  overqualified  people  may  siphon  funding 
from  other  priorities. 

The  USCG  and  Navy  processes  for  determining  manpower  requirements  are 
similar,  however,  some  fundamental  differences  exist.  For  example,  the  USCG  has 
adopted  many  Navy  processes  as  its  own,  yet  has  centralized  the  authority  for  shore 
manpower  requirements  determination  unlike  the  Navy.  Regardless  of  similarities  and 
differences,  there  is  benefit  to  the  USCG  and  the  Navy  remaining  appraised  of  the  other 
service’s  best  practices  and  lessons  learned.  Exchange  between  the  services  will 
contribute  to  optimizing  their  respective  manpower  requirements  determination 
processes. 

The  intent  of  a  Manpower  Requirement  Determination  Automated  Information 
System  (MRD  AIS)  is  to  improve  the  accuracy  of  determining  manpower  requirements, 
alleviate  time  intensive  manual  processes,  standardize  manpower  analysis,  increase 
transparency,  bolster  adaptability,  optimize  manpower  allocation,  and  identify  alternative 
staffing  solutions.  The  purpose  of  this  study  was  to  demonstrate  the  potential  value  in 
implementing  a  MRD  AIS  in  the  USCG.  Modeling  the  factors  that  contribute  to 
determining  manpower  requirements  in  an  entity-relationship  diagram  (ERD),  and 
subsequently  testing  via  a  relational  database  confirmed  that  implementing  a  similar 
model  and  database  would  yield  efficiency  in  manpower  requirements  determination. 
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B,  CONCLUSIONS  AND  RECOMMENDATIONS 

The  primary  research  question  is: 

What  are  the  data  requirements  to  determine  Coast  Guard  manpower 
requirements? 

Conclusion:  As  a  result  of  a  thorough  review  of  the  USCG  Staffing  Logic  and 
Manpower  Requirements  (SLMR)  Manuals,  Volumes  I-IV;  associated  job  aids  and 
templates,  and  recent  MRAs  for  the  following  organizational  elements:  Judge  Advocate 
General  (JAG)  Program,  Maritime  Force  Protection  Unit  (MFPU),  Regional  Dive  Locker 
Pacific,  and  WTGB  140’  (Bay)  Class  Icebreaking  Harbor  Tug,  a  comprehensive  list  of 
entities,  attributes,  and  their  respective  definitions  was  drafted.  Nouns  describing  people, 
work  or  workload,  and  organization  were  the  focal  points  to  determine  data  requirements. 
This  information  is  consolidated  in  the  Data  Dictionary  located  in  Appendix  A. 

Recommendation:  The  USCG  Manpower  Requirements  Determination  Division 
ought  to  commit  to  the  full  implementation  of  an  MRD  AIS.  This  type  of  tool,  consistent 
with  this  project’s  findings,  will  yield  efficiencies  associated  with  MRD.  The  potential 
implementation  supports  the  nature  of  twenty-first  century  threats  and  fiscal  challenges, 
getting  the  right  people,  to  the  right  places,  at  the  right  times,  with  the  right  skills.  The 
entities,  attributes,  and  relationships  identified  in  this  research  should  be  reviewed  to 
either  revise  the  MRD  AIS  delivered  by  the  contractor  or  used  as  the  foundation  for  a 
new  MRD  AIS. 

The  secondary  research  question  is: 

How  does  the  Navy  determine  manpower  requirements,  and  how  does  their 
process  inform  this  research? 

Conclusion:  The  Navy  uses  site  visits  and  Navy  Manpower  Requirements 
Systems  (NMRS)  to  determine  Fleet  manpower  requirements,  and  34  individual, 
decentralized  Budget  Submitting  Offices  to  determine  manpower  requirements  for  their 
respective  programs. 
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The  USCG  and  Navy  processes  for  determining  manpower  requirements  are 
similar  in  regard  to  workload  measurement  and  Fleet  manpower  requirements 
determination.  The  greatest  similarity  is  that  the  USCG  and  the  Navy  use  NMRS  to  pair 
workload  information,  specifically  workload  hours,  with  occupational  knowledge,  skills, 
and  abilities  to  quantify  and  qualify  Fleet  manpower  requirements.  NMRS  produces  a 
recommended  manpower  mix  based  on  validated  workload  information.  The  USCG  is 
able  to  use  this  Navy  product,  because  the  nature  of  work  between  the  services  is 
comparable. 

Recommendation:  The  USCG  Manpower  Requirements  Determination  Division 
should  continue  to  leverage  its  relationship  with  the  Navy  Analysis  Manpower  Center 
(NAVMAC),  and  its  use  of  NMRS.  Currently,  NMRS  appears  to  be  a  most  capable  tool 
at  the  USCG’s  disposal.  Synergy  between  the  USCG  Manpower  Requirements 
Determination  Division  and  NAVMAC  may  contribute  to  optimizing  both  organizations’ 
MRD  processes. 

C.  FURTHER  RESEARCH 

A  team  of  students  from  acquisition,  computer  science,  manpower,  and  systems 
engineering  curriculums  and  USCG  Headquarters  subject  matter  experts  should  refine 
and  advance  the  work  completed  within  this  project.  Particular  capabilities  that  should  be 
added  to  this  project’s  database  include  code  to  perform  mathematical  computations  and 
to  yield  summary  data,  work  and  workload  distribution,  and  optimization  capabilities. 
Interface  with  other  USCG  databases  including  the  Abstract  of  Operations  System,  the 
Training  Management  Tool,  the  Aviation  Logistics  Management  Information  System, 
and  Direct  Access  may  also  be  helpful.  It  is  possible,  however,  that  an  MRD  AIS  may 
alleviate  the  need  for  one  or  more  of  these  existing  databases. 

Another  method  to  accelerate  the  USCG’s  implementation  of  an  MRD  AIS  is  to 
conduct  research  that  would  determine  how  NMRS  would  need  to  be  modified  to  also 
contribute  to  determining  shore  manpower  requirements.  Ultimately,  a  standardized 
MRD  AIS  that  would  determine  Fleet  and  shore  manpower  requirements  would  yield 
efficiency. 
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APPENDIX  A.  DATA  DICTIONARY 


Entity 

Definition 

Reference 

Contractor 

A  person  hired  by  the  Coast  Guard  to  contribute  to  the  completion  of  an 
MRA. 

Attribute 

Definition 

Reference 

ContractorlD 

An  alphanumeric  code  used  to  identify  contractors. 

LastName 

The  contractor's  last  name. 

FirstName 

The  contractor's  first  name. 

Contra  ctorOrganization 

The  organization  for  which  the  contractor  works. 

ContractorContactNumber 

The  contractor's  phone  number. 

Contra  ctorContactE-mail 

The  contractor's  e-mail  address. 
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Entity 

Definition 

Reference 

M  R  ATe  a  m  M  e  m  b  e  r 

A  coast  guard  member  or  contractor  that  works  on  one  or  more  teams  to 
accomplish  MRA(s). 

Attribute 

Definition 

Reference 

M  RATea  m  Me  m  berl  D 

An  alphanumeric  code  used  to  identify  MRA  team  members. 

MRATeamID 

An  alphanumeric  code  used  to  identify  MRA  teams. 

MRAID 

An  alphanumeric  code  used  to  identify  MRAs. 

ContractorlD 

An  alphanumeric  code  used  to  identify  contractors. 

EMPLID 

A  numeric  code  used  to  identify  coast  guard  members. 

MRAPosition 

The  roles  filled  by  members  of  the  MRA  team  e.g.,  requestor,  project 
manager,  analyst,  etc. 
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Entity 

Definition 

Reference 

MRATeam 

The  collection  of  Coast  Guard  members  and  contractors  that  work  on 
respective  MRAs. 

Attribute 

Definition 

Reference 

MRATeamID 

An  alphanumeric  code  used  to  identify  MRA  teams. 

TeamName 

The  name  of  the  MRA  team. 
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Definition 

Reference 

MRA  is  the  manpower  requirements  analysis. 

Attribute 

Definition 

Reference 

MRAID 

An  alphanumeric  code  used  to  identify  MRAs. 

OEName 

The  name  of  the  organizational  element. 

MRACategory 

An  assignment  given  to  an  MRA  request:  A-  directed,  B  -  sponsor- 
contracted,  C  -  periodic  review,  D  -  sponsor-requested,  E  -  Modeling  & 
simulation 

(Commandant,  2010a,  p. 
2-4) 

MRAPriority 

A  score  yielded  by  the  MRA  Request  Prioritization  Decision  Matrix  that 
dictates  the  priority  of  an  MRA  within  a  category 

(Commandant,  2010a, 
pp.  2-5  -  2-6) 

MR  A  Level 

The  level  of  analytical  rigor  applied  to  an  MRA:  Level  1  -  Manpower 
Estimate  Report,  Level  2  -  Workload  Consolidation,  Level  3  -  Workload 
Validation,  Level  4  -  Workload  Observation 

(Commandant,  2014,  p. 
3.C.I.) 

Comments 

Amplifying  information  provided  in  regard  to  the  MRA. 
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Entity  Definition 

MRARequest  Coast  Guard  form  5310  that  initiates  a  MRA 


Attribute 

Definition 

Reference 

MRARequestID 

An  alphanumeric  code  used  to  identify  MRA  requests. 

RequestDate 

The  date  the  MRA  request  was  submitted. 

OEName 

The  name  of  the  organizational  element. 

OEType 

Organizational  element  type  e.g.  DCMS/DCO  staff  element,  district  staff, 
operational  unit,  etc. 

(Commandant,  2014,  p. 
3-1-43) 

OEMRATrigger 

The  specific  reason(s)  that  prompted  the  need  for  the  analysis. 

(Commandant,  2014,  p. 
3-1-35) 

OEDateLastMRA 

The  last  date  an  MRA  was  completed. 

OESize 

The  size  of  the  organizational  element. 

ImportanceToSponsor 

The  importance  to  the  sponsor  e.g.,  essential  to  mission  readiness,  aligns 
with  strategic  goals,  etc. 

(Commandant,  2014,  p. 
3-1-44) 

MRAID 

An  alphanumeric  code  used  to  identify  MRAs. 

RequestorOfficeName 

The  office  in  which  the  requestor  works. 

Comments 

Amplifying  information  provided  in  regard  to  the  MRA. 

Reference 
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Entity 

Definition 

Reference 

Requestor 

The  senior  member  that  initiated  the  MRA  request. 

Attribute 

Definition 

Reference 

RequestorOfficeName 

The  office  in  which  the  requestor  works. 

PrimaryPocRank 

The  primary  point  of  contact's  rank. 

PrimaryLastName 

The  primary  point  of  contact's  last  name. 

PrimaryFirstName 

The  primary  point  of  contact's  first  name. 

SecondaryPocRank 

The  secondary  point  of  contact's  rank. 

SecondaryPocLastName 

The  secondary  point  of  contact's  last  name. 

SecondaryPocFirstName 

The  secondary  point  of  contact's  first  name. 
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Entity 

Definition 

Reference 

OE 

The  subject  of  the  MRA. 

Attribute 

Definition 

Reference 

OEName 

The  name  of  the  organizational  element. 

HQUnit 

Binary  indication  of  whether  or  not  the  organizational  element  is  a  Coast 
Guard  headquarters'  unit. 

FieldUnit 

Binary  indication  of  whether  or  not  the  organizational  element  is  a  Coast 
Guard  field  unit. 
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Entity 

Definition 

Reference 

GeneralAssumption 

General  assumptions  provide  direction  in  regard  to  how  the  MRA  should 
be  executed. 

Entity 

Definition 

Reference 

GenAssumpID 

An  alphanumeric  code  used  to  identify  general  assumptions. 

MRAID 

An  alphanumeric  code  used  to  identify  MRAs. 

GenAssumpDescription 

General  assumption  description. 

DateAdded 

The  date  on  which  the  assumption  was  added. 

DateModified 

The  date  on  which  the  assumption  was  modified. 

Comments 

Amplifying  information  provided  in  regard  to  the  general  assumption. 
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Entity 

Definition 

Reference 

MDMBusinessRule 

MDM  Business  Rules  direct  how  the  overall  MRA  should  be  executed. 

Attribute 

Definition 

Reference 

RuleSet 

Numeric  code  used  to  identify  the  MDM  rule  set. 

MRAID 

An  alphanumeric  code  used  to  identify  MRAs. 

RuleDescription 

MDM  rule  description. 
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Entity 

Definition 

Reference 

WorkCenter 

A  portion  of  an  organizational  element  e.g.,  department,  division,  office, 
branch,  etc. 

Attribute 

Definition 

Reference 

WorkCenterName 

The  work  center's  name. 

WorkCenterDescription 

A  description  of  the  work  center. 
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Entity 

Definition 

Reference 

Workload 

The  activity  of  a  body  or  mind  which  can  be  measured  against  standards 
in  time,  quantity  or  quality  including  but  not  limited  to  operation  of 
equipment,  watches,  military  duties,  military  assemblies,  maintenance, 
administration,  support,  utility  tasks,  evolutions,  training,  supervision, 
job-related  conversations,  etc. 

(Commandant,  2014,  p. 
Glossary) 

Attribute 

Definition 

Reference 

TaskID 

The  alphanumeric  code  used  to  identify  the  task. 

WorkloadID 

The  alphanumeric  code  used  to  identify  the  workload. 

Frequency 

Data  field  used  to  indicate  the  rate  of  occurrence  for  a  work  item. 

(Commandant,  2010a,  p. 
3-16) 

TaskMonth 

Data  field  used  to  indicate  the  month  or  months  in  which  the  OE 
accomplishes  the  work  (for  quarterly,  semi-annual,  or  annual  work).  This 
provides  the  ability  to  conduct  a  cyclical  work/workload  analysis  during 
the  modeling  and  simulation  phase. 

(Commandant,  2010a,  p. 
3-17) 

TaskCount 

Data  field  used  to  record  the  maximum  number  of  times  a  work  item  is 
accomplished  during  a  specified  period.  The  count  may  be  multiplied  to 
include  the  number  of  persons  involved.  It  may  also  be  fractionalized  for 
work  with  annual  frequencies  exceeding  every  4  years  for  example  .2 
count  with  a  frequency  of  annual  would  be  every  five  years. 

(Commandant,  2010a,  p. 
3-17) 

WorkloadRaw 

The  knowledge  base  task  mean. 

(Commandant,  2010a,  p. 
3-50) 

WorkloadFactor 

A  workload  factor  is  an  index  or  unit  of  measure  that  is  consistently 
relatable  to  the  work  required  to  accomplish  a  specifically  defined 
responsibility;  e.g.,  the  number  of  officers  ably  serviced  by  an  assignment 
officer,  or  the  number  of  personnel  records  ably  serviced  by  a  Yeoman. 

(Commandant,  2010a,  p. 
5-8) 
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WorkloadComputed 

OE  workload  computed  is  the  workload  for  each  task  based  on  the 
workload  minutes  per  week  times  the  work  count  for  each  task 
performed  at  the  OE. 

(Commandant,  2010a,  p. 
3-52) 

WorkloadMultipler 

The  workload  multiplier  is  applied  to  workload  computations  to  account 
for  various  process  slowing  events. 

(Commandant,  2010a,  p. 
3-52) 

WorkloadFinished 

Workload  finished  is  the  workload  with  appropriately  applied  PF&D 
multiplier  expressed  in  minutes  per  week  for  each  OE  task. 

(Commandant,  2010a,  p. 
3-56) 

DurationOptimistic 

Data  field  that  represents  the  most  efficient  time  required  to  complete  a 
single  work  item.  Work  Duration  is  recorded  using  selectable  responses 
such  as  5-10  minutes,  10-15  minutes,  etc.  If  available  selectable 
responses  cannot  adequately  explain  the  duration  of  the  work  item  the 
analyst  should  record  the  reason  for  this  in  the  analyst  notes  column  of 
the  work  matrix. 

(Commandant,  2010a,  p. 
3-17) 

DurationProbable 

Data  field  that  represents  the  most  common  time  required  to  complete  a 
single  work  item.  Work  Duration  is  recorded  using  selectable  responses 
such  as  5-10  minutes,  10-15  minutes,  etc.  If  available  selectable 
responses  cannot  adequately  explain  the  duration  of  the  work  item  the 
analyst  should  record  the  reason  for  this  in  the  analyst  notes  column  of 
the  work  matrix. 

(Commandant,  2010a,  p. 
3-17) 

DurationPessimistic 

Data  field  that  represents  the  least  efficient  time  required  to  complete  a 
single  work  item.  Work  Duration  is  recorded  using  selectable  responses 
such  as  5-10  minutes,  10-15  minutes,  etc.  If  available  selectable 
responses  cannot  adequately  explain  the  duration  of  the  work  item  the 
analyst  should  record  the  reason  for  this  in  the  analyst  notes  column  of 
the  work  matrix. 

(Commandant,  2010a,  p. 
3-17) 
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Entity 

Definition 

Reference 

Task 

Task  and  work  item  are  synonymous,  but  task  is  used  to  remain 
eonsistent  with  the  Accomplishment  Based  Curriculum  Development 
system.  Basic  identification  of  work  accomplished  or  services 
performed.  Tasks  should  be  easy  to  identify,  convenient  for  obtaining 
productive  count,  and  usable  for  scheduling,  planning,  and  costing. 

(Commandant,  2014,  p. 
Glossary) 

Attribute 

Definition 

Reference 

TaskID 

The  alphanumeric  code  used  to  identify  the  task. 

TaskTitle 

A  descriptive  title  of  the  work  item 

(Commandant,  2010a,  p. 
3-13) 

TaskReference 

A  unique  alphanumeric  reference  for  each  work  item 

(Commandant,  2010a,  p. 
3-13) 

TaskDescription 

A  more  detailed  description  of  the  work  item 

(Commandant,  2010a,  p. 
3-13) 

TaskSponsor 

The  program  manager  for  the  specific  work  item  being  described  for 
example  CG-OOH  for  Civil  Rights  related  work  items 

(Commandant,  2010a,  p. 
3-13) 

TaskOESubstructure 

A  descriptive  field  that  points  to  specific  work  center  within  the  OE  in 
which  the  work  item  is  performed. 

(Commandant,  2010a,  p. 
3-13) 

TaskLaborTypeCharacteristics 

Information  about  the  work  item  that  may  indicate  the  use  of  one 
type  of  manpower  over  another  for  example  the  work  item  is  military 
essential  and  therefore  requires  military  personnel  to  complete  it. 

(Commandant,  2010a,  p. 
3-13) 

ReferenceClass 

Work  is  categorized  by  the  source  from  which  it  was  discovered,  as 
either  documented  (work  base  on  official  doctrine,  directives,  or 
other  authoritative,  written  sources  of  information)  or  undocumented 
(work  based  on  unofficial  or  informal  practices,  policies  or  rules  that 
must  be  adjudicated  during  the  MRA  process  in  order  to  be  included 
in  the  manpower  determinants  model). 

(Commandant,  2010a,  p. 
3-14) 
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TaskType 

Used  to  classify  work/workload  as  either  direct  (work  conducted  to 
accomplish  the  OE's  mission(s),  function(s)  and  goal(s))  or  indirect 
(work  that  does  not  directly  support  an  OE's  assigned  mission(s), 
function(s),  and  goal(s),  but  is  performed  in  order  to  manage 
organizational,  personnel,  and  capital  assets) 

(Commandant,  2010a,  p. 
3-14) 

TaskClass 

Used  to  group  work  items  into  designated  categories  for  example  SAR 
(search  and  rescue  -  direct  work),  SML  (supervision,  management,  and 
leadership  -  indirect  work),  COL  (collateral  duties  -  indirect  work),  TRA 
(training  -  indirect  work),  and  HRM  (human  resource  management  - 
direct  work). 

(Commandant,  2010a,  p. 
3-14) 

TaskSsic 

A  broad  function  category  that  describes  the  work  item  in  terms  of 
the  most  applicable  standard  subject  identification  code  (SSIC)  for  the 
specific  type  of  referenced  work. 

(Commandant,  2010a,  p. 
3-14) 

TaskFunction 

A  more  detailed  description  of  documented  work  items,  using  the 
noun  title  of  the  SSIC. 

(Commandant,  2010a,  p. 
3-14) 

TaskManpowerType 

Identifies  the  particular  labor  source  linked  to  a  work  item  (military 
active/reserve,  civilian,  contractor,  or  volunteer)  that  generally  has  a 
common  set  of  workforce  availability  and  constraints. 

(Commandant,  2010a,  p. 
3-15) 

TaskEnvironment 

Identifies  the  primary  place  that  the  work  item  is  performed  for 
example  at  sea  or  inport,  on  or  off  watch,  etc. 

(Commandant,  2010a,  p. 
3-15) 

OEName 

The  name  of  the  organizational  element. 

MAID 

The  alphanumeric  code  used  to  identify  the  major  accomplishment. 
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Entity 

Definition 

Reference 

Position 

A  designated  placeholder  as  indicated  in  the  personnel  allowance  list  or 
determined  to  be  necessary  per  an  MRA.  A  position  represents  all  jobs,  duties, 
skills,  responsibilities,  and  supervisory  relationships  assigned  to  an  employee. 

(Commandant,  2014,  p. 
Glossary) 

Attribute 

Definition 

Reference 

PositionID 

The  alphanumeric  code  used  to  identify  the  position. 

PositionTitle 

The  title  of  the  position. 

PresenceOnPAL 

Binary  indication  of  whether  or  not  the  position  is  on  the  personnel  allowance 
list. 

PALPositionN  umber 

The  position  number  on  the  personnel  allowance  list. 

DateAdded 

The  date  on  which  the  position  was  added. 

DateModified 

The  date  on  which  the  position  was  modified. 

Comments 

Amplifying  information  provided  in  regard  to  a  position. 
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Definition 

Reference 

A  particular  position  achieved  within  a  hierarchy. 

Attribute 

Definition 

Reference 

RankAbbreviation 

The  rank's  abbreviation. 

RankName 

The  name  of  a  rank. 
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Definition 

Reference 

Rate 

The  specialty  of  an  enlisted  member. 

Attribute 

Definition 

Reference 

RateAbbreviation 

The  rate's  abbreviation. 

RateName 

The  name  of  a  rate. 
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Entity 

Definition 

Reference 

WorkWeekAvailability 

Coast  Guard  human  capital  management  processes  use  work  week 
availability  as  planning  factors  help  define  manpower  needed  to 
accomplish  identified  missions  and  associated  work  requirements  for 
various  organizational  elements.  Standard  workweeks  are  guidelines  for 
sustained  personnel  use  and  should  not  be  viewed  as  binding  on  a 
command's  ability  to  manage  its  unit  workforce. 

(Commandant,  2014,  p. 
3-1-21) 

Attribute 

Definition 

Reference 

PositionID 

The  alphanumeric  code  used  to  identify  a  position. 

AvailabilityHrsWk 

The  number  of  hours  per  week  each  labor  source  is  available  to  dedicate 
to  productive  work  activities. 

(Commandant,  2010a,  p. 
3-24) 

Planning  Factor 

A  conversion  factor  applied  to  workload  raw  for  each  task. 

(Commandant,  2010a,  p. 
3-50) 

Manpower  Required 

The  number  and  types  of  positions  required  to  successfully  accomplish 
all  of  the  work  assigned  to  the  OE. 

(Commandant,  2010a,  p. 
4-3) 

Overall  Unit  Work 

Utilization 

Range  at  which  a  position  requirement  or  set  of  requirements  in  an  OE 
may  be  either  not  fully  utilized,  likely  to  be  optimally  utilized,  at  or  near 
maximum  load  and  exceed  target  load,  or  exceed  maximum  load  and  are 
unlikely  to  meet  workload  demands. 

(Commandant,  2010a,  p. 
4-7) 
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Entity 

Definition 

Reference 

Assumption 

Assumptions  are  characteristics  about  an  OE,  its  mission  and  workers  that 
must  be  assumed  to  provide  a  starting  point  from  which  to  determine  the 
appropriate  manning. 

(Commandant,  2010a,  p. 
3-25) 

Attribute 

Definition 

Reference 

AssumptionID 

The  alphanumeric  code  used  identify  an  assumption. 

AssumptionDescription 

The  description  of  the  assumption. 

DateAdded 

The  date  on  which  the  assumption  was  added. 

DateModified 

The  date  on  which  the  assumption  was  modified. 

Comments 

Amplifying  information  provided  in  regard  to  an  assumption. 
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Entity 

Definition 

Reference 

Constraint 

Business  rules  that  must  be  taken  into  aceount  when  identifying 
work  requirements  or  assigning  workload  to  a  particular  labor  force 
in  the  MRA  process.  Represent  statutory  or  policy  level  limitations 
on  the  amount  of  work  certain  Coast  Guard  personnel  can  do,  or 
the  type  of  workers  assigned  to  do  the  work.  Factors  act  as  filters 
through  which  final  manpower  options  are  modeled. 

(Commandant, 
2014,  p.  Glossary) 

Attribute 

Definition 

Reference 

ConstraintID 

The  alphanumeric  code  used  to  identify  the  constraint. 

ConstraintType 

Work  designation,  workforce  type,  work  location,  operational 
status,  specialty/ rate  type,  rank/paygrade  type,  cutter 
employment  standards,  watchstanding  duty  requirements,  or 
crew  endurance  factors. 

(Commandant, 
2010a,  pp.  3-19  - 
3-24) 

ConstraintDescription 

The  description  of  the  constraint. 

DateAdded 

The  date  on  which  the  constraint  was  added. 

DateModified 

The  date  on  which  the  constraint  was  modified. 

Comments 

Amplifying  information  provided  in  regard  to  a  constraint. 
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Entity 

Definition 

Reference 

M  a  j  0  r  Acco  m  p  1  i  s  h  m  e  n  t 

Output  of  behavior  that  has  direct  value  to  the  goals  of  the  job  and  the 
organization. 

(Commandant,  2014,  p. 
Glossary) 

Attribute 

Definition 

Reference 

MAID 

The  alphanumeric  code  used  to  identify  the  major  accomplishment. 

MAName 

The  name  of  the  major  accomplishment. 

MADescription 

The  description  of  the  major  accomplishment. 
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Entity 

Definition 

Reference 

Competency 

Knowledge,  skills,  abilities,  personal  characteristics,  qualifications, 
training,  education,  licenses/certifications,  and  prior  assignments 
needed  to  perform  work  to  a  predetermined,  measurable  standard. 

(Commandant,  2014,  p. 
Glossary) 

Attribute 

Definition 

Reference 

CompetencyCode 

An  alphanumeric  code  up  to  eight  characters  long  that 
uniquely  identifies  a  competency  in  DA.  This  code  is  established  when 
the  competency  is  created  in  DA.  Users  will  only  see  this  code  when 
creating  ad  hoc  competency  queries. 

(Commandant,  2005,  p. 
2-3) 

CompetencyTitle 

The  title  of  the  competency. 

CompetencyDescription 

An  alphanumeric  acronym  or  abbreviation  up  to  10  characters  long 
that  provides  enough  information  to  allow  a  person  to  identify  a 
competency  uniquely.  Used  for  code  validation  when  creating  ad  hoc 
competency  queries. 

(Commandant,  2005,  p. 
2-3) 

CompetencyType 

The  assigned  functional  or  mission  area  where  the 
requirement  of  the  competency  is  concentrated;  i.e..  Afloat 

Operations;  Aviation;  Command,  Control,  Communications,  Computers 
and  Information  Technology  (C4IT).  Competencies  may  be  assigned 
multiple  types. 

(Commandant,  2005,  p. 
2-3) 
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CompetencyCategory 

The  classification  of  a  competency  establishing  the  kind  of 
competency;  knowledge,  skill,  ability,  or  other  (behavior). 

(Commandant,  2005,  p. 
2-3) 

CompetencyProficiencyScale 

The  proficiency  rating  scale,  displayed  as 

"Rating"  in  DA  is  used  to  establish  the  level  of  competence.  This  scale 
applies  to  both  persons  and  positions.  For  the  individual  member,  it 
describes  the  proficiency  level  the  person  has  achieved.  For  a  position, 
it  describes  the  level  of  proficiency  needed  to  be  successful  in  the 
position.  The  associated  levels  may  vary  with  each  competency.  Levels 
typically  include:  None,  Little,  Good,  Very  Good,  and  Expert. 

(Commandant,  2005,  p. 
2-3) 

CompetencyDefinition 

The  complete  description  of  the  competency.  The 

competency  definition  is  written  in  a  specific  manner,  describing  what 

the  holder  of  the  competency  can  do. 

(Commandant,  2005,  p. 
2-3) 

CompetencyRequirements 

The  complete  listing  of  all  qualification 

requirements  (schools.  Personnel  Qualification  Standard  [PQS],  time, 
prerequisite  competencies,  etc.),  and  any  restriction  on  who  the 
competency  may  be  assigned  to  (military  only,  civilian,  enlisted. 
Auxiliary,  or  pay  grade). 

(Commandant,  2005,  p. 
2-3) 

Competencyimportance 

This  field  is  used  to  establish  the  desired/required  need  for  the 
competency  for  an  assigned  position.  This  characteristic  is  only  used 
when  a  competency  is  assigned  to  a  position.  See  Table  2-1  for 
importance  descriptions. 

(Commandant,  2005,  p. 
2-3) 

DateAdded 

The  date  on  which  the  competency  was  added. 

DateModified 

The  date  on  which  the  competency  was  modified. 

Comments 

Amplifying  information  provided  in  regard  to  a  competency. 
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Entity 

Definition 

Reference 

Option 

A  result  from  the  modeling  effort. 

Attribute 

Definition 

Reference 

OptionID 

The  alphanumeric  code  used  to  identify  an  option. 

OptionDescription 

The  description  of  the  option. 

MRD 

Binary  indication  of  whether  or  not  a  particular  option  is  the  MRD. 

DateAdded 

The  date  on  which  the  option  was  added. 

DateModified 

The  date  on  which  the  option  was  modified. 

Comments 

Amplifying  information  in  regard  to  an  option. 
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Entity _ 

Allowance 


Attribute _ 

AllowancelD 

AllowanceType 

Allowance 

WorkFacility 

location) 

WorkCategory 

WorkCondition 

environment) 

DateAdded 

DateModified 

Comments 


(work 


(work 


Definition 

A  standard  applied  to  workload  to  adjust  for  factors  including  working 
conditions,  physical  &  mental  exertion  requirements,  etc. 


Definition 

An  alphanumeric  code  used  to  identify  an  allowance. 

The  specific  type  of  personal,  fatigue,  or  delay  consideration. 

The  name  of  the  specific  allowance. 

The  performance  environment,  for  example  boat,  cutter,  shore  facility 

Work  activity  or  series  of  work  actions  for  example  evolutions,  general 

administration,  maintenance,  training,  watchstanding 

General  physical  environment  in  which  the  work  is  performed  for 

example  hanger,  moored,  office,  underway 

The  date  on  which  the  allowance  was  added. 

The  date  on  which  the  allowance  was  modified. 

Amplifying  information  provided  in  regard  to  an  allowance. 


Reference 

(Commandant,  2010a,  p. 
3-52) 


Reference 


MRA  PF&D  Template 


MRA  PF&D  Template 


MRA  PF&D  Template 
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Entity 

Definition 

Reference 

ReferenceDocument 

A  document  that  directs  or  provides  amplifying  information  in  regard  to 
an  organizational  element's  work  or  workload. 

Attribute 

Definition 

Reference 

Title 

The  title  of  the  reference  document. 

DhsDODSsic 

If  applicable,  the  standard  subject  identification  code  used  to  identify  a 
reference  document. 

PublicationDate 

The  date  the  reference  document  was  published. 

PublicationOrganization 

The  organization  that  published  the  reference  document. 
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Definition 

Reference 

A  series  of  questions  that  facilitate  work  measurement. 

Attribute 

Definition 

Reference 

SurveylD 

An  alphanumeric  code  used  to  identify  the  survey. 

Survey Date 

The  date  the  survey  was  conducted. 

SurveyAudience 

A  description  of  to  whom  the  survey  was  distributed. 
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Entity 

Definition 

Reference 

SurveyQuestion 

A  question  asked  on  the  survey. 

Attribute 

Definition 

Reference 

SurveyQuestionID 

An  alphanumeric  code  used  to  identify  the  survey  question. 

SurveyQuestionDescription 

A  representation  of  the  question  asked  on  the  survey. 

Survey  ID 

An  alphanumeric  code  used  to  identify  the  survey. 
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Entity 

Definition 

Reference 

SurveyAnswer 

The  answer  provided  to  a  survey  question. 

Attribute 

Definition 

Reference 

SurveyQuestionID 

An  alphanumeric  code  used  to  identify  the  survey  question. 

SurveyAnswerlD 

An  alphanumeric  code  used  to  identify  the  survey  answer. 

SurveyAnswer 

The  response  provided  to  the  survey  question. 

RespondentN  umber 

A  numeric  code  assigned  to  survey  respondents  other  than  an  employee 
ID.  This  code  facilitates  anonymity  of  survey  respondents,  but  allows 
summary  statistics  to  be  tied  to  survey  respondent  demographics 
including  rank  and  rate. 
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Entity 

Definition 

Reference 

SurveyRespondent 

A  person  that  responds  to  a  survey. 

Attribute 

Definition 

Reference 

RespondentN  umber 

A  numeric  code  assigned  to  survey  respondents  other  than  an  employee 
ID.  This  code  facilitates  anonymity  of  survey  respondents,  but  allows 
summary  statistics  to  be  tied  to  survey  respondent  demographics 
including  rank  and  rate. 

RespondentRate 

The  rate  of  the  survey  respondent. 

RespondentRank 

The  rank  of  the  survey  respondent. 
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Entity 

Definition 

Reference 

Interview 

A  verbal  exchange  between  a  member  at  the  organizational  element 
being  analyzed  and  an  MRA  team  member  to  facilitate  work 
measurement. 

Attribute 

Definition 

Reference 

InterviewlD 

An  alphanumeric  code  used  to  identify  the  interview. 

InterviewDate 

The  date  the  interview  was  conducted. 

EMPLID 

A  numeric  code  used  to  identify  coast  guard  members. 
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Entity 

Definition 

Reference 

InterviewQuestion 

A  question  asked  during  the  interview. 

Attribute 

Definition 

Reference 

InterviewQuestionID 

An  alphanumeric  code  used  to  identify  the  interview  question. 

InterviewQuestionDescription 

A  representation  of  the  question  that  was  asked  during  the  interview. 

InterviewlD 

An  alphanumeric  code  used  to  identify  the  interview. 
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Entity 

Definition 

Reference 

InterviewAnswer 

The  answer  to  an  interview  question. 

Attribute 

Definition 

Reference 

InterviewQuestionID 

An  alphanumeric  code  used  to  identify  the  interview  question. 

InterviewAnswerlD 

An  alphanumeric  code  used  to  identify  the  interview  answer. 

InterviewAnswer 

The  response  to  the  interview  question. 
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